目录

Table of Contents

第四页

Page iv

软件工程：从业者的方法

SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH

由 McGraw-Hill Education 出版，地址：2 Penn Plaza, New York, NY 10121。版权所有 © 2020 McGraw-Hill Education。版权所有。美国印刷。未经麦格劳-希尔教育事先书面同意，不得以任何形式或任何方式复制或分发本出版物的任何部分，或将其存储在数据库或检索系统中，包括但不限于在任何网络或其他地方电子存储或传输，或用于远程学习的广播。

Published by McGraw-Hill Education, 2 Penn Plaza, New York, NY 10121. Copyright © 2020 by McGraw-Hill Education. All rights reserved. Printed in the United States of America. No part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written consent of McGraw-Hill Education, including, but not limited to, in any network or other electronic storage or transmission, or broadcast for distance learning.

一些辅助设备，包括电子和印刷组件，可能无法向美国以外的客户提供。

Some ancillaries, including electronic and print components, may not be available to customers outside the United States.

本书采用无酸纸印刷。

This book is printed on acid-free paper.

1 2 3 4 5 6 7 8 9 LCR 24 23 22 21 20 19

1 2 3 4 5 6 7 8 9 LCR 24 23 22 21 20 19

ISBN 978-1-260-54800-6（装订版）

ISBN 978-1-260-54800-6 (bound edition)

MHID 1-260-54800-7（装订版）

MHID 1-260-54800-7 (bound edition)

封面图片：© RL Hausdorf/Shutterstock

Cover Image: ©R.L. Hausdorf/Shutterstock

出现在书页或书末的所有出处均被视为版权页的延伸。

All credits appearing on page or at the end of the book are considered to be an extension of the copyright page.

文本中列出的互联网地址在发布时是准确的。包含网站并不表示作者或麦格劳-希尔教育的认可，并且麦格劳-希尔教育不保证这些网站上提供的信息的准确性。

The Internet addresses listed in the text were accurate at the time of publication. The inclusion of a website does not indicate an endorsement by the authors or McGraw-Hill Education, and McGraw-Hill Education does not guarantee the accuracy of the information presented at these sites.

mheducation.com/highered

mheducation.com/highered

第v页

Page v

第六页

Page vi

关于作者_ _

About the Author

Roger S. Pressman是国际公认的软件工程顾问和作家。近五年来，他担任过软件工程师、经理、教授、作家、顾问和企业家。

Roger S. Pressman is an internationally recognized consultant and author in software engineering. For almost five decades, he has worked as a software engineer, a manager, a professor, an author, a consultant, and an entrepreneur.

Pressman 博士是 RS Pressman & Associates, Inc. 的总裁，该公司是一家专门帮助公司建立有效的软件工程策略的咨询公司。多年来，他开发了一套改进软件工程实践的技术和工具。^{他还是 EVANNEX ®}的创始人兼首席技术官，EVANNEX ® 是一家汽车售后市场公司，专门为特斯拉电动汽车系列设计和制造配件。

Dr. Pressman was president of R. S. Pressman & Associates, Inc., a consulting firm that specialized in helping companies establish effective software engineering strategies. Over the years he developed a set of techniques and tools that improved software engineering practice. He is also the founder and chief technology officer of EVANNEX^®, an automotive aftermarket company that specializes in the design and manufacture of accessories for the Tesla line of electric vehicles.

普雷斯曼博士是十本书的作者，其中包括两本小说以及许多技术和管理论文。他曾担任IEEE Software和The Cutter IT Journal的编辑委员会成员，并且是IEEE Software的“Manager”专栏的编辑。

Dr. Pressman is the author of ten books, including two novels, and many technical and management papers. He has been on the editorial boards of IEEE Software and The Cutter IT Journal and was editor of the “Manager” column in IEEE Software.

Pressman 博士是一位著名的演讲者，曾在多个重大行业会议上发表过主题演讲。他曾在国际软件工程会议和许多其他行业会议上发表过教程。他是 ACM、IEEE、Tau Beta Pi、Phi Kappa Phi、Eta Kappa Nu 和 Pi Tau Sigma 的成员。

Dr. Pressman is a well-known speaker, keynoting a number of major industry conferences. He has presented tutorials at the International Conference on Software Engineering and at many other industry meetings. He has been a member of the ACM, IEEE, Tau Beta Pi, Phi Kappa Phi, Eta Kappa Nu, and Pi Tau Sigma.

Bruce R. Maxim担任软件工程师、项目经理、教授、作家和顾问已有三十多年。他的研究兴趣包括软件工程、用户体验设计、严肃游戏开发、人工智能和工程教育。

Bruce R. Maxim has worked as a software engineer, project manager, professor, author, and consultant for more than thirty years. His research interests include software engineering, user experience design, serious game development, artificial intelligence, and engineering education.

Maxim 博士是密歇根大学迪尔伯恩分校计算机与信息科学教授和工程学院教授。他在工程与计算机科学学院建立了游戏实验室。他发表了有关计算机算法动画、游戏开发和工程教育的论文。他是一本畅销的计算机科学入门书籍和两本经过编辑的软件工程研究论文集的合著者。作为他在密歇根大学迪尔伯恩分校工作的一部分，Maxim 博士监督了数百个基于行业的软件开发项目。

Dr. Maxim is professor of computer and information science and collegiate professor of engineering at the University of Michigan–Dearborn. He established the GAME Lab in the College of Engineering and Computer Science. He has published papers on computer algorithm animation, game development, and engineering education. He is coauthor of a best-selling introductory computer science text and two edited collections of software engineering research papers. Dr. Maxim has supervised several hundred industry-based software development projects as part of his work at the University of Michigan–Dearborn.

Maxim 博士的专业经验包括管理医学院的研究信息系统、指导医学院的教学计算以及担任统计程序员。Maxim 博士曾担任一家游戏开发公司的首席技术官。

Dr. Maxim’s professional experience includes managing research information systems at a medical school, directing instructional computing for a medical campus, and working as a statistical programmer. Dr. Maxim served as the chief technology officer for a game development company.

马克西姆博士曾获得多项杰出教学奖、杰出社区服务奖和杰出教师管理奖。他是 Sigma Xi、Upsilon Pi Epsilon、Pi Mu Epsilon、计算机协会、IEEE 计算机协会、美国工程教育协会、女工程师协会和国际游戏开发者协会的成员。

Dr. Maxim was the recipient of several distinguished teaching awards, a distinguished community service award, and a distinguished faculty governance award. He is a member of Sigma Xi, Upsilon Pi Epsilon, Pi Mu Epsilon, Association of Computing Machinery, IEEE Computer Society, American Society for Engineering Education, Society of Women Engineers, and International Game Developers Association.

第二十七页

Page xxvii

前言_

Preface

当计算机软件成功时——当它满足使用它的人的需求时，当它在很长一段时间内完美地运行时，当它易于修改甚至更易于使用时——它可以而且确实使事情变得更好。但是，当软件出现故障时——当用户不满意、容易出错、难以更改甚至更难使用时——糟糕的事情就可能而且确实会发生。我们都希望构建能够让事情变得更好的软件，避免潜伏在失败努力阴影下的坏事情。为了取得成功，我们在设计和构建软件时需要遵守纪律。我们需要一种工程方法。

When computer software succeeds—when it meets the needs of the people who use it, when it performs flawlessly over a long period of time, when it is easy to modify and even easier to use—it can and does change things for the better. But when software fails—when its users are dissatisfied, when it is error prone, when it is difficult to change and even harder to use—bad things can and do happen. We all want to build software that makes things better, avoiding the bad things that lurk in the shadow of failed efforts. To succeed, we need discipline when software is designed and built. We need an engineering approach.

距离本书第一版的撰写已经过去近四十年了。在那段时间里，软件工程已经从一个由相对少数狂热者实践的晦涩想法发展成为一门合法的工程学科。今天，它被认为是一个值得认真研究、认真研究和激烈辩论的主题。在整个行业中，软件工程师已经取代程序员或编码员成为首选职位。软件过程模型、软件工程方法和软件工具已被广泛的行业领域成功采用。

It has been nearly four decades since the first edition of this book was written. During that time, software engineering has evolved from an obscure idea practiced by a relatively small number of zealots to a legitimate engineering discipline. Today, it is recognized as a subject worthy of serious research, conscientious study, and tumultuous debate. Throughout the industry, software engineer has replaced programmer or coder as the job title of preference. Software process models, software engineering methods, and software tools have been adopted successfully across a broad spectrum of industry segments.

尽管管理者和从业者都认识到需要对软件采取更加严格的方法，但他们仍在争论应用纪律的方式。许多个人和公司仍然随意开发软件，即使他们构建的系统是为当今最先进的技术服务的。许多专业人士和学生不了解现代方法。结果，我们生产的软件质量受到影响，并且发生了不好的事情。此外，关于软件工程方法的真正本质的争论和争议仍在继续。软件工程的现状是一项对比研究。人们的态度已经改变，取得了进步，但在该学科完全成熟之前还有很多工作要做。

Although managers and practitioners alike recognize the need for a more disciplined approach to software, they continue to debate the manner in which discipline is to be applied. Many individuals and companies still develop software haphazardly, even as they build systems to service today’s most advanced technologies. Many professionals and students are unaware of modern methods. And as a result, the quality of the software that we produce suffers, and bad things happen. In addition, debate, and controversy about the true nature of the software engineering approach continue. The status of software engineering is a study in contrasts. Attitudes have changed, progress has been made, but much remains to be done before the discipline reaches full maturity.

第九版新内容

New to the Ninth Edition

《软件工程：从业者的方法》第九版旨在作为成熟工程学科的指南。与之前的八版一样，第九版面向学生和从业者，保留了其作为行业专业人士指南的吸引力，以及对高年级本科生或研究生一年级学生的全面介绍。

The ninth edition of Software Engineering: A Practitioner’s Approach is intended to serve as a guide to a maturing engineering discipline. The ninth edition, like the eight editions that preceded it, is intended for both students and practitioners, retaining its appeal as a guide for the industry professional and a comprehensive introduction to the student at the upper-level undergraduate or first-year graduate level.

第二十八页第九版不仅仅是一个简单的更新。本书经过修订和重组，以改进教学流程并强调新的重要的软件工程过程和实践。此外，我们还进一步增强了本书广受欢迎的“支持系统”，提供了一套全面的学生、教师和专业资源来补充本书的内容。

Page xxviiiThe ninth edition is considerably more than a simple update. The book has been revised and restructured to improve pedagogical flow and emphasize new and important software engineering processes and practices. In addition, we have further enhanced the popular “support system” for the book, providing a comprehensive set of student, instructor, and professional resources to complement the content of the book.

读过过去几版《软件工程：从业者的方法》的读者会注意到，第九版的页长实际上有所减少。我们的目标是简洁，从教学的角度使这本书变得更强大，并且让那些想要读完整本书的读者不那么畏惧。著名数学家和物理学家布莱斯·帕斯卡（Blaise Pascal）有这样一个轶事：在给朋友写一封过长的信时，帕斯卡以这句话结尾。“我想给你写封短一点的信，但我没有时间。” 当我们致力于第九版的简洁时，我们开始欣赏帕斯卡的话。

Readers of the past few editions of Software Engineering: A Practitioner’s Approach will note that the ninth edition has actually been reduced in page length. Our goal was concision, making the book stronger from a pedagogical viewpoint and less daunting for the reader who desires to journey through the entire book. An anecdote, attributed to Blaise Pascal, the famous mathematician and physicist, goes like this: In writing a overly long letter to a friend, Pascal ended with this sentence. “I wanted to write you a shorter letter, but I didn’t have the time.” As we worked on concision for the ninth edition, we came to appreciate Pascal’s words.

第九版共30章，分为五个部分。该组织可以更好地划分主题，并为可能没有时间在一个学期内完成整本书的教师提供帮助。

The 30 chapters of the ninth edition are organized into five parts. This organization better compartmentalizes topics and assists instructors who may not have the time to complete the entire book in one term.

第 1 部分“软件过程”提出了软件过程的各种不同观点，考虑了几个重要的过程模型和框架，使我们能够解决规范性过程哲学和敏捷过程哲学之间的争论。第 2 部分“建模”介绍了分析和设计方法，重点是面向对象技术和 UML 建模。还考虑了基于模式的设计和移动计算应用程序的设计。本节扩大了用户体验设计的覆盖范围。第 3 部分，质量和安全，介绍了使软件团队能够评估软件质量、审查软件工程工作产品、执行 SQA 程序以及应用有效的测试策略和策略的概念、过程、技术和方法。此外，我们还提出了可以插入增量软件开发模型的软件安全实践。第 4 部分“管理软件项目”介绍与规划、管理和控制软件开发项目的人员相关的主题。第 5 部分，高级主题，考虑软件过程改进和软件工程趋势。整本书都包含盒装功能，以展示（虚构的）软件团队的考验和磨难，并提供与章节主题相关的方法和工具的补充材料。

Part 1, The Software Process, presents a variety of different views of software process, considering several important process models and frameworks that allow us to address the debate between prescriptive and agile process philosophies. Part 2, Modeling, presents analysis and design methods with an emphasis on object-oriented techniques and UML modeling. Pattern-based design and design for mobility computing applications are also considered. The coverage of user experience design has been expanded in this section. Part 3, Quality and Security, presents the concepts, procedures, techniques, and methods that enable a software team to assess software quality, review software engineering work products, conduct SQA procedures, and apply an effective testing strategy and tactics. In addition, we present software security practices that can be inserted into incremental software development models. Part 4, Managing Software Projects, presents topics that are relevant to those who plan, manage, and control a software development project. Part 5, Advanced Topics, considers software process improvement and software engineering trends. Boxed features are included throughout the book to present the trials and tribulations of a (fictional) software team and to provide supplementary materials about methods and tools that are relevant to chapter topics.

第九版的五部分组织使教师能够根据可用时间和学生需求对主题进行“聚类”。整个一学期的课程可以围绕五个部分中的一个或多个部分构建。软件工程调查课程将从所有五个部分中选择章节。强调分析和设计的软件工程课程将从第 1 部分和第 2 部分中选择主题。面向测试的软件工程课程将从第 1 部分和第 3 部分中选择主题，并简要介绍第 2 部分。“管理课程”将强调第 1 部分和第 2 部分。 1 和 4。通过以这种方式组织第九版，我们试图为教师提供多种教学选择。在每种情况下，第九版的内容均由SEPA、9/e 支持系统的以下要素进行补充。第xxxx页

The five-part organization of the ninth edition enables an instructor to “cluster” topics based on available time and student need. An entire one-term course can be built around one or more of the five parts. A software engineering survey course would select chapters from all five parts. A software engineering course that emphasizes analysis and design would select topics from Parts 1 and 2. A testing-oriented software engineering course would select topics from Parts 1 and 3, with a brief foray into Part 2. A “management course” would stress Parts 1 and 4. By organizing the ninth edition in this way, we have attempted to provide an instructor with a number of teaching options. In every case the content of the ninth edition is complemented by the following elements of the SEPA, 9/e Support System.Page xxix

其他资源

Additional Resources

可以通过讲师网站访问各种资源，包括包含问题解决方案的广泛在线学习中心、带有软件工程清单的各种基于网络的资源、不断发展的“微型工具”集合以及全面的案例研究。专业资源提供数百个分类的网络参考，使学生能够更详细地探索软件工程，以及参考库包含数百个可下载参考资料的链接，提供高级软件工程信息的深入来源。此外，还包括完整的在线教师指南和补充教材以及数百张可用于讲座的 PowerPoint 幻灯片。

A wide variety of resources can be accessed through the instructor website, including an extensive online learning center encompassing problem solutions, a variety of Web-based resources with software engineering checklists, an evolving collection of “tiny tools,” and comprehensive case studies. Professional Resources provide several hundred categorized web references which allow students to explore software engineering in greater detail, along with a reference library with links to several hundred downloadable references providing an in-depth source of advanced software engineering information. Additionally, a complete online Instructor’s Guide and supplementary teaching materials along with several hundred PowerPoint slides that may be used for lectures are included.

《软件工程教师指南：从业者的方法》提出了开展各种类型的软件工程课程的建议、与课程结合进行的各种软件项目的建议、选定问题的解决方案以及许多有用的教学辅助工具。

The Instructor’s Guide for Software Engineering: A Practitioner’s Approach presents suggestions for conducting various types of software engineering courses, recommendations for a variety of software projects to be conducted in conjunction with a course, solutions to selected problems, and a number of useful teaching aids.

与其在线支持系统相结合， 《软件工程：从业者的方法》第九版提供了仅靠教科书无法实现的灵活性和内容深度。

When coupled with its online support system, the ninth edition of Software Engineering: A Practitioner’s Approach provides flexibility and depth of content that cannot be achieved by a textbook alone.

Bruce Maxim 牵头为《软件工程：从业者的方法》第九版开发新内容，而 Roger Pressman 担任主编并在特定情况下提供贡献。

Bruce Maxim has taken the lead in developing new content for the ninth edition of Software Engineering: A Practitioner’s Approach, while Roger Pressman has served as editor-in-chief as well as providing contributions in select circumstances.

致谢特别感谢卡内基梅隆大学软件工程学院的 Nancy Mead，她撰写了有关软件安全工程的章节；渥太华大学的 Tim Lethbridge 帮助我们开发 UML 和 OCL 示例，并开发了本书随附的案例研究；科尔比学院 (Colby College) 的 Dale Skrien 开发了附录 1 中的 UML 教程；密歇根大学迪尔伯恩分校的 William Grosky 与他的学生 Terry Ruas 在附录 2 中概述了数据科学；以及我们的澳大利亚同事 Margaret Kellow 更新了本书附带的教学网络材料。此外，我们还要感谢 Austin Krauss 从高级软件工程师的角度提供了对视频游戏行业软件开发的见解。

Acknowledgments Special thanks go to Nancy Mead from Software Engineering Institute at Carnegie Mellon University who wrote the chapter on software security engineering; Tim Lethbridge of the University of Ottawa who assisted us in the development of UML and OCL examples and developed the case study that accompanies this book; Dale Skrien of Colby College who developed the UML tutorial in Appendix 1; William Grosky of the University of Michigan–Dearborn who developed the overview of data science in Appendix 2 with his student Terry Ruas; and our Australian colleague Margaret Kellow for updating the pedagogical Web materials that accompany this book. In addition, we would like to thank Austin Krauss for providing insight into software development in the video game industry from his perspective as a senior software engineer.

特别感谢BRM：我很高兴有机会与罗杰合作编写本书的第九版。在我撰写本书期间，我的儿子本杰明已成为一名软件工程经理，我的女儿凯瑟琳则利用她的艺术背景创作了本书章节中出现的人物。我很高兴看到他们已经成为成年人，并享受与他们的孩子（艾拉、艾玛和塞尔玛）在一起的时光。我非常感谢我的妻子诺玛，她在我利用空闲时间写这本书时给予了我热情的支持。

Special Thanks BRM: I am grateful to have had the opportunity to work with Roger on the ninth edition of this book. During the time I have been working on this book, my son, Benjamin, has become a software engineering manager and my daughter, Katherine, used her art background to create the figures that appear in the book chapters. I am quite pleased to see the adults they have become and enjoy my time with their children (Isla, Emma, and Thelma). I am very grateful to my wife, Norma, for her enthusiastic support as I filled my free time working on this book.

第xxx页RSP：随着本书版本的演变，我的儿子马修和迈克尔已经从男孩成长为男人。他们的成熟、性格和在现实世界中的成功给了我很大的启发。在遵循自己的职业道路多年之后，我们三人现在在 2012 年创立的一家企业中共同工作。没有什么比这更让我感到自豪的了。我的两个儿子现在都有了自己的孩子，玛雅和莉莉，他们又开始了新的一代。最后，向我的妻子芭芭拉表达我的爱和感谢，感谢她在办公室里忍受了很多很多时间，并鼓励了“这本书”的另一版。

Page xxxRSP: As the editions of this book have evolved, my sons, Mathew and Michael, have grown from boys to men. Their maturity, character, and success in the real world have been an inspiration to me. After many years of following our own professional paths, the three of us now work together in a business that we founded in 2012. Nothing has filled me with more pride. Both of my sons now have children of their own, Maya and Lily, who start still another generation. Finally, to my wife, Barbara, my love and thanks for tolerating the many, many hours in the office and encouraging still another edition of “the book.”

布鲁斯·R·马克西姆

Bruce R. Maxim

罗杰·S·普雷斯曼

Roger S. Pressman

第xxxi页

Page xxxi

第1页

Page 1

第2页“因为如果你是，”他说，“你会更加兴奋。您已经看到了我们的下一代产品，这是我们的客户会渴望的东西。。。没有双关语的意思。”

Page 2“Because if you were,” he said, “you’d be a lot more excited. You’ve gotten a peek at our next generation product and that’s something that our customers would kill for . . . no pun intended.”

我们坐在地球上最成功的游戏开发商之一的开发区。多年来，他演示的前几代游戏销量超过 5000 万份，创造了数十亿美元的收入。

We sat in a development area at one of the most successful game developers on the planet. Over the years, earlier generations of the game he demoed sold over 50 million copies and generated billions of dollars in revenue.

“那么，这个版本什么时候上市？” 我问。

“So, when will this version be on the market?” I asked.

他耸耸肩。“大约五个月后，我们还有很多工作要做。”

He shrugged. “In about five months, and we’ve still got a lot of work to do.”

他负责一个包含超过三百万行代码的应用程序中的游戏玩法和人工智能功能。

He had responsibility for game play and artificial intelligence functionality in an application that encompassed more than three million lines of code.

“你们使用任何软件工程技术吗？” 我问道，半期待着他会笑着摇摇头。

“Do you guys use any software engineering techniques?” I asked, half-expecting that he’d laugh and shake his head.

他停下来想了一会儿。然后他缓缓地点了点头。“我们会根据我们的需求调整它们，但当然，我们会使用它们。”

He paused and thought for a moment. Then he slowly nodded. “We adapt them to our needs, but sure, we use them.”

“在哪里？” 我试探着问道。

“Where?” I asked, probing.

“我们的问题通常是如何转化创意人员提出的要求。”

“Our problem is often translating the requirements the creatives give us.”

“创意？” 我打断道。

“The creatives?” I interrupted.

“你知道，那些设计故事、角色以及所有让游戏大受欢迎的东西的人。我们必须接受他们给我们的东西，并制定一套技术要求，使我们能够构建游戏。”

“You know, the guys who design the story, the characters, all the stuff that make the game a hit. We have to take what they give us and produce a set of technical requirements that allow us to build the game.”

“那么在要求确定之后呢？”

“And after the requirements are established?”

他耸耸肩。“我们必须扩展和调整前一版本游戏的架构并创建新产品。我们必须根据需求创建代码，通过日常构建测试代码，并执行您书中推荐的许多事情。”

He shrugged. “We have to extend and adapt the architecture of the previous version of the game and create a new product. We have to create code from the requirements, test the code with daily builds, and do lots of things that your book recommends.”

“你知道我的书吗？” 老实说我很惊讶。

“You know my book?” I was honestly surprised.

“当然，在学校用过它。那里有很多东西。”

“Sure, used it in school. There’s a lot there.”

“我和你这里的一些朋友谈过，他们对我书中的内容更加持怀疑态度。”

“I’ve talked to some of your buddies here, and they’re more skeptical about the stuff in my book.”

他皱起了眉头。“看，我们不是 IT 部门或航空航天公司，所以我们必须定制您所提倡的内容。但底线是一样的——我们需要生产高质量的产品，而我们能够以可重复的方式实现这一目标的唯一方法就是适应我们自己的软件工程技术子集。”

He frowned. “Look, we’re not an IT department or an aerospace company, so we have to customize what you advocate. But the bottom line is the same—we need to produce a high-quality product, and the only way we can accomplish that in a repeatable fashion is to adapt our own subset of software engineering techniques.”

“随着时间的推移，你的子集会发生怎样的变化？”

“And how will your subset change as the years pass?”

他停了下来，仿佛在思考未来。“游戏将会变得更大、更复杂，这是肯定的。随着更多竞争的出现，我们的开发时间将会缩短。慢慢地，游戏本身将迫使我们应用更多的开发纪律。如果我们不这样做，我们就死定了。”

He paused as if to ponder the future. “Games will become bigger and more complex, that’s for sure. And our development timelines will shrink as more competition emerges. Slowly, the games themselves will force us to apply a bit more development discipline. If we don’t, we’re dead.”

*****

*****

计算机软件仍然是世界舞台上最重要的技术。这也是意外后果定律的一个典型例子。六十年前，没有人能够预见到软件会成为商业、科学和工程不可或缺的技术；现在，软件已经成为商业、科学和工程领域不可或缺的技术。该软件将能够创造新技术（例如基因工程和纳米技术）、扩展现有技术（例如电信）以及彻底改变旧技术（例如媒体）；该软件将成为个人计算机革命背后的驱动力；消费者将使用其移动设备购买软件应用程序；随着“按需”软件公司通过网络浏览器提供即时功能，该软件将从产品慢慢演变为服务；软件公司将比所有工业时代的公司变得更大、更有影响力；或者一个庞大的软件驱动网络将发展并改变一切，从图书馆研究到消费者购物，从政治话语到年轻人（而不是那么年轻）的约会习惯。第3页

Computer software continues to be the single most important technology on the world stage. And it’s also a prime example of the law of unintended consequences. Sixty years ago no one could have predicted that software would become an indispensable technology for business, science, and engineering; that software would enable the creation of new technologies (e.g., genetic engineering and nanotechnology), the extension of existing technologies (e.g., telecommunications), and the radical change in older technologies (e.g., the media); that software would be the driving force behind the personal computer revolution; that software applications would be purchased by consumers using their mobile devices; that software would slowly evolve from a product to a service as “on-demand” software companies deliver just-in-time functionality via a Web browser; that a software company would become larger and more influential than all industrial-era companies; or that a vast software-driven network would evolve and change everything from library research to consumer shopping to political discourse to the dating habits of young (and not so young) adults.Page 3

随着软件重要性的不断增长，软件社区不断尝试开发技术，使构建和支持高质量计算机程序变得更容易、更快、更便宜。其中一些技术针对特定应用领域（例如网站设计和实现）；其他人专注于技术领域（例如，面向对象的系统或面向方面的编程）；还有一些具有广泛的基础（例如，Linux 等操作系统）。然而，我们还没有开发出一种能够完成这一切的软件技术，而且未来出现这种技术的可能性很小。然而，人们却把自己的工作、舒适、安全、娱乐、决定以及生命都押在了计算机软件上。最好是对的。

As software’s importance has grown, the software community has continually attempted to develop technologies that will make it easier, faster, and less expensive to build and support high-quality computer programs. Some of these technologies are targeted at a specific application domain (e.g., website design and implementation); others focus on a technology domain (e.g., object-oriented systems or aspect-oriented programming); and still others are broad based (e.g., operating systems such as Linux). However, we have yet to develop a software technology that does it all, and the likelihood of one arising in the future is small. And yet, people bet their jobs, their comforts, their safety, their entertainment, their decisions, and their very lives on computer software. It better be right.

本书提出了一个可供那些构建计算机软件的人（必须正确使用它的人）使用的框架。该框架包含一个流程、一组方法和一系列我们称之为软件工程的工具。

This book presents a framework that can be used by those who build computer software—people who must get it right. The framework encompasses a process, a set of methods, and an array of tools that we call software engineering.

要构建能够应对二十一世纪挑战的软件，您必须认识到一些简单的现实：

To build software that is ready to meet the challenges of the twenty-first century, you must recognize a few simple realities:

• 软件几乎已经深深嵌入我们生活的方方面面。^{对特定应用程序1}提供的特性和功能感兴趣的人数急剧增加。在开发软件解决方案之前，应共同努力理解问题。

• Software has become deeply embedded in virtually every aspect of our lives. The number of people who have an interest in the features and functions provided by a specific application¹ has grown dramatically. A concerted effort should be made to understand the problem before a software solution is developed.

• 个人、企业和政府对信息技术的要求逐年变得越来越复杂。现在，大型团队创建计算机程序。曾经在可预测的独立计算环境中实现的复杂软件现在已嵌入到从消费电子产品到医疗设备再到自动驾驶汽车的所有内容中。设计已成为一项关键活动。

• The information technology requirements demanded by individuals, businesses, and governments grow increasingly complex with each passing year. Large teams of people now create computer programs. Sophisticated software that was once implemented in a predictable, self-contained computing environment is now embedded inside everything from consumer electronics to medical devices to autonomous vehicles. Design has become a pivotal activity.

• 个人、企业和政府越来越依赖软件进行战略和战术决策以及日常运营和控制。如果软件出现故障，人们和大型企业可能会遇到从轻微的不便到灾难性的后果。软件应该表现出高质量。

• Individuals, businesses, and governments increasingly rely on software for strategic and tactical decision making as well as day-to-day operations and control. If the software fails, people and major enterprises can experience anything from minor inconvenience to catastrophic consequences. Software should exhibit high quality.

• 随着特定应用程序的感知价值不断增长，其用户群和寿命也可能会增长。随着其用户群和使用时间的增加，适配和增强的需求也会增长。软件应该是可维护的。

• As the perceived value of a specific application grows, the likelihood is that its user base and longevity will also grow. As its user base and time in use increase, demands for adaptation and enhancement will also grow. Software should be maintainable.

这些简单的现实引出了一个结论：所有形式和跨所有应用领域的软件都应该被设计。这就引出了本书的主题——软件工程。

These simple realities lead to one conclusion: Software in all its forms and across all its application domains should be engineered. And that leads us to the topic of this book—software engineering.

第4页

Page 4

1.1 软件的本质

1.1 The Nature of Software

如今，软件扮演着双重角色。它是一种产品，也是交付产品的工具。作为一种产品，它提供了由计算机硬件或更广泛地由本地硬件可访问的计算机网络体现的计算潜力。无论是驻留在移动设备、桌面、云中，还是大型计算机或自主机器中，软件都是信息转换器——生成、管理、获取、修改、显示或传输信息，这些信息可以像单个位或像增强现实表示一样复杂，该表示源自从数十个独立来源获取的数据，然后叠加在现实世界上。作为用于交付产品的工具，软件是计算机控制（操作系统）、信息通信（网络）以及其他程序（软件工具和环境）创建和控制的基础。

Today, software takes on a dual role. It is a product, and the vehicle for delivering a product. As a product, it delivers the computing potential embodied by computer hardware or, more broadly, by a network of computers that are accessible by local hardware. Whether it resides within a mobile device, on the desktop, in the cloud, or within a mainframe computer or autonomous machine, software is an information transformer—producing, managing, acquiring, modifying, displaying, or transmitting information that can be as simple as a single bit or as complex as an augmented-reality representation derived from data acquired from dozens of independent sources and then overlaid on the real world. As the vehicle used to deliver a product, software acts as the basis for the control of the computer (operating systems), the communication of information (networks), and the creation and control of other programs (software tools and environments).

软件提供了我们这个时代最重要的产品——信息。它转换个人数据（例如个人的金融交易），以便数据在本地环境中更有用；管理商业信息以提高竞争力；它提供了通往全球信息网络（例如互联网）的门户；并提供获取各种形式信息的手段。它还提供了一个可能威胁个人隐私的工具，以及一个使恶意者能够实施犯罪行为的网关。

Software delivers the most important product of our time—information. It transforms personal data (e.g., an individual’s financial transactions) so that the data can be more useful in a local context; it manages business information to enhance competitiveness; it provides a gateway to worldwide information networks (e.g., the Internet); and provides the means for acquiring information in all its forms. It also provides a vehicle that can threaten personal privacy and a gateway that enables those with malicious intent to commit criminal acts.

过去 60 年来，计算机软件的作用发生了重大变化。硬件性能的显着提高、计算架构的深刻变化、内存和存储容量的大幅增加以及各种奇特的输入和输出选项都催生了更加复杂的基于计算机的系统。当系统成功时，复杂性可以产生令人眼花缭乱的结果，但它们也可能给那些必须构建和保护复杂系统的人带来巨大的问题。

The role of computer software has undergone significant change over the last 60 years. Dramatic improvements in hardware performance, profound changes in computing architectures, vast increases in memory and storage capacity, and a wide variety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. Sophistication and complexity can produce dazzling results when a system succeeds, but they can also pose huge problems for those who must build and protect complex systems.

如今，庞大的软件产业已成为工业化世界经济的主导因素。由软件专家组成的团队，每个人都专注于交付复杂应用程序所需的技术的一部分，已经取代了早期时代的孤独程序员。然而，向孤独的程序员提出的问题与构建现代基于计算机的系统时提出的问题是相同的：²

Today, a huge software industry has become a dominant factor in the economies of the industrialized world. Teams of software specialists, each focusing on one part of the technology required to deliver a complex application, have replaced the lone programmer of an earlier era. And yet, the questions that were asked of the lone programmer are the same questions that are asked when modern computer-based systems are built:²

• 为什么软件需要这么长时间才能完成？

• Why does it take so long to get software finished?

• 为何开发成本如此之高？

• Why are development costs so high?

• 为什么我们在将软件提供给客户之前无法找到所有错误？

• Why can’t we find all errors before we give the software to our customers?

• 为什么我们要花费如此多的时间和精力来维护现有的程序？

• Why do we spend so much time and effort maintaining existing programs?

• 为什么我们在软件开发和维护过程中仍然难以衡量进度？

• Why do we continue to have difficulty in measuring progress as software is being developed and maintained?

第5页这些问题以及许多其他问题都是对软件及其开发方式的关注的体现，这种关注导致了软件工程实践的采用。

Page 5These, and many other questions, are a manifestation of the concern about software and how it is developed—a concern that has led to the adoption of software engineering practice.

1.1.1 定义软件

1.1.1 Defining Software

如今，大多数专业人士和许多公众都认为他们了解软件。但他们真的吗？

Today, most professionals and many members of the public at large feel that they understand software. But do they?

毫无疑问可以提供其他更完整的定义。但更正式的定义可能不会显着提高您的理解。为了实现这一目标，重要的是要检查软件的特征，这些特征使其不同于人类构建的其他东西。软件是逻辑系统元素，而不是物理系统元素。因此，软件有一个与硬件显着不同的基本特征：软件不会“磨损”。

There is no question that other more complete definitions could be offered. But a more formal definition probably won’t measurably improve your understanding. To accomplish that, it’s important to examine the characteristics of software that make it different from other things that human beings build. Software is a logical rather than a physical system element. Therefore, software has one fundamental characteristic that makes it considerably different from hardware: Software doesn’t “wear out.”

图 1.1将硬件故障率描述为时间的函数。这种关系通常被称为“浴缸曲线”，表明硬件在其生命早期表现出相对较高的故障率（这些故障通常归因于设计或制造缺陷）；缺陷得到纠正，并且故障率在一段时间内下降到稳态水平（希望非常低）。然而，随着时间的推移，由于硬件组件受到灰尘、振动、滥用、极端温度和许多其他环境问题的累积影响，故障率再次上升。简而言之，硬件开始磨损。

Figure 1.1 depicts failure rate as a function of time for hardware. The relationship, often called the “bathtub curve,” indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected, and the failure rate drops to a steady-state level (hopefully, quite low) for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative effects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out.

第6页软件不易受到导致硬件磨损的环境问题的影响。因此，从理论上讲，软件的故障率曲线应该采用图1.2所示的“理想化曲线”的形式。未被发现的缺陷将导致程序生命周期早期的高失败率。然而，这些已得到纠正，并且曲线变平，如图所示。理想化曲线是对软件实际故障模型的过度简化。然而，含义很明确——软件不会磨损。但确实会恶化！

Page 6Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failure rates early in the life of a program. However, these are corrected and the curve flattens as shown. The idealized curve is a gross oversimplification of actual failure models for software. However, the implication is clear—software doesn’t wear out. But it does deteriorate!

这种看似矛盾的现象最好通过考虑图 1.2中的实际曲线来解释。在其生命周期中，^{有 3 个}软件会发生变化。当进行更改时，很可能会引入错误，导致故障率曲线出现峰值，如“实际曲线”所示（图1.2）。在曲线返回到原始稳态故障率之前，需要进行另一次更改，导致曲线再次尖峰。慢慢地，最低故障率水平开始上升——软件由于变化而恶化。

This seeming contradiction can best be explained by considering the actual curve in Figure 1.2. During its life,³ software will undergo change. As changes are made, it is likely that errors will be introduced, causing the failure rate curve to spike as shown in the “actual curve” (Figure 1.2). Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again. Slowly, the minimum failure rate level begins to rise—the software is deteriorating due to change.

磨损的另一个方面说明了硬件和软件之间的差异。当硬件组件磨损时，会用备件进行更换。没有软件备件。每个软件故障都表明设计中或将设计转换为机器可执行代码的过程中存在错误。因此，适应变更请求的软件维护任务比硬件维护复杂得多。

Another aspect of wear illustrates the difference between hardware and software. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. Therefore, the software maintenance tasks that accommodate requests for change involve considerably more complexity than hardware maintenance.

第7页

Page 7

1.1.2 软件应用领域

1.1.2 Software Application Domains

如今，七大类计算机软件给软件工程师带来了持续的挑战：

Today, seven broad categories of computer software present continuing challenges for software engineers:

系统软件。为服务其他程序而编写的程序的集合。一些系统软件（例如，编译器、编辑器和文件管理实用程序）处理复杂但确定的^{4 种}信息结构。其他系统应用程序（例如操作系统组件、驱动程序、网络软件、电信处理器）主要处理不确定的数据。

System software. A collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) processes complex, but determinate,⁴ information structures. Other systems applications (e.g., operating system components, drivers, networking software, telecommunications processors) process largely indeterminate data.

应用程序软件。解决特定业务需求的独立程序。该领域的应用程序以促进业务运营或管理/技术决策的方式处理业务或技术数据。

Application software. Stand-alone programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making.

工程/科学软件。一系列广泛的“数字运算”或数据科学项目，范围从天文学到火山学，从汽车应力分析到轨道动力学，从计算机辅助设计到消费者消费习惯，从基因分析到气象学。

Engineering/scientific software. A broad array of “number-crunching” or data science programs that range from astronomy to volcanology, from automotive stress analysis to orbital dynamics, from computer-aided design to consumer spending habits, and from genetic analysis to meteorology.

嵌入式软件。驻留在产品或系统中，用于为最终用户和系统本身实现和控制特性和功能。嵌入式软件可以执行有限且深奥的功能（例如，微波炉的键盘控制）或提供重要的功能和控制能力（例如，汽车中的数字功能，例如燃油控制、仪表板显示和制动系统）。

Embedded software. Resides within a product or system and is used to implement and control features and functions for the end user and for the system itself. Embedded software can perform limited and esoteric functions (e.g., key pad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems).

产品线软件。由可重复使用的组件组成，旨在提供特定功能供许多不同的客户使用。它可能专注于有限且深奥的市场（例如，库存控制产品）或尝试解决大众消费者市场。

Product-line software. Composed of reusable components and designed to provide specific capabilities for use by many different customers. It may focus on a limited and esoteric marketplace (e.g., inventory control products) or attempt to address the mass consumer market.

网络/移动应用程序。这种以网络为中心的软件类别涵盖广泛的应用程序，包括基于浏览器的应用程序、云计算、基于服务的计算以及驻留在移动设备上的软件。

Web/mobile applications. This network-centric software category spans a wide array of applications and encompasses browser-based apps, cloud computing, service-based computing, and software that resides on mobile devices.

人工智能软件。利用启发式⁵来解决无法进行常规计算或直接分析的复杂问题。该领域的应用包括机器人、决策系统、模式识别（图像和语音）、机器学习、定理证明和游戏。

Artificial intelligence software. Makes use of heuristics⁵ to solve complex problems that are not amenable to regular computation or straightforward analysis. Applications within this area include robotics, decision-making systems, pattern recognition (image and voice), machine learning, theorem proving, and game playing.

全球数以百万计的软件工程师正在努力从事其中一个或多个类别的软件项目。在某些情况下，正在构建新系统，但在许多其他情况下，现有应用程序正在得到纠正、调整和增​​强。年轻的软件工程师开发比她年龄还大的程序并不罕见！过去几代软件人在我们讨论的每个类别中都留下了遗产。希望这一代人留下的遗产能够减轻未来软件工程师的负担。

Millions of software engineers worldwide are hard at work on software projects in one or more of these categories. In some cases, new systems are being built, but in many others, existing applications are being corrected, adapted, and enhanced. It is not uncommon for a young software engineer to work on a program that is older than she is! Past generations of software people have left a legacy in each of the categories we have discussed. Hopefully, the legacy to be left behind by this generation will ease the burden on future software engineers.

第8页

Page 8

1.1.3 遗留软件

1.1.3 Legacy Software

数十万个计算机程序属于上一小节讨论的七个广泛应用领域之一。其中一些是最先进的软件。但其他程序更老，在某些情况下更老。

Hundreds of thousands of computer programs fall into one of the seven broad application domains discussed in the preceding subsection. Some of these are state-of-the-art software. But other programs are older, in some cases much older.

这些较旧的程序（通常称为遗留软件）自 20 世纪 60 年代以来一直是人们持续关注和关注的焦点。Dayani-Fard 和他的同事 [Day99] 用以下方式描述遗留软件：

These older programs—often referred to as legacy software—have been the focus of continuous attention and concern since the 1960s. Dayani-Fard and his colleagues [Day99] describe legacy software in the following way:

这些更改可能会产生传统软件中经常出现的额外副作用——质量差。⁶遗留系统有时具有不可扩展的设计、复杂的代码、糟糕或不存在的文档、从未存档的测试用例和结果以及管理不善的变更历史记录。这个列表可能很长。然而，这些系统通常支持“核心功能，并且对业务来说是不可或缺的”。该怎么办？

These changes may create an additional side effect that is often present in legacy software—poor quality.⁶ Legacy systems sometimes have inextensible designs, convoluted code, poor or nonexistent documentation, test cases and results that were never archived, and a poorly managed change history. The list can be quite long. And yet, these systems often support “core functions and are indispensable to the business.” What to do?

唯一合理的答案可能是：什么也不做，至少在遗留系统必须经历一些重大改变之前。如果遗留软件能够满足用户的需求并且运行可靠，那么它就没有损坏，也不需要修复。然而，随着时间的推移，遗留系统通常会因以下一个或多个原因而演变：

The only reasonable answer may be: Do nothing, at least until the legacy system must undergo some significant change. If the legacy software meets the needs of its users and runs reliably, it isn’t broken and does not need to be fixed. However, as time passes, legacy systems often evolve for one or more of the following reasons:

• 软件必须进行调整以满足新计算环境或技术的需求。

• The software must be adapted to meet the needs of new computing environments or technology.

• 必须增强软件才能满足新的业务需求。

• The software must be enhanced to implement new business requirements.

• 该软件必须进行扩展，才能与其他更现代的系统或数据库一起使用。

• The software must be extended to make it work with other more modern systems or databases.

• 该软件必须重新架构，以使其在不断发展的计算环境中可行。

• The software must be re-architected to make it viable within an evolving computing environment.

当这些演变模式发生时，必须重新设计遗留系统，使其在未来仍然可行。现代软件工程的目标是“设计基于进化概念的方法；也就是说，软件系统不断变化，新的软件系统可以从旧的软件系统中构建出来，并且。。。所有人都必须相互互动和合作”[Day99]。

When these modes of evolution occur, a legacy system must be reengineered so that it remains viable in the future. The goal of modern software engineering is to “devise methodologies that are founded on the notion of evolution; that is, the notion that software systems change continually, new software systems can be built from the old ones, and . . . all must interact and cooperate with each other” [Day99].

1.2 学科定义

1.2 Defining the Discipline

IEEE [IEE17] 为软件工程制定了以下定义：

The IEEE [IEE17] has developed the following definition for software engineering:

软件工程：应用系统的、规范的、可量化的方法来开发、操作和维护软件；即工程在软件上的应用。

Software Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

第9页然而，一个软件团队采用的“系统性、规范性和可量化”方法可能会给另一个软件团队带来负担。我们需要纪律，但我们也需要适应性和敏捷性。

Page 9And yet, a “systematic, disciplined, and quantifiable” approach applied by one software team may be burdensome to another. We need discipline, but we also need adaptability and agility.

软件工程是一种分层技术。参考图 1.3，任何工程方法（包括软件工程）都必须依赖于组织对质量的承诺。您可能听说过全面质量管理 (TQM) 或六西格码，以及类似的理念⁷，它们培养了持续流程改进的文化。正是这种文化最终带来了更有效的软件工程方法。支持软件工程的基石是质量焦点。

Software engineering is a layered technology. Referring to Figure 1.3, any engineering approach (including software engineering) must rest on an organizational commitment to quality. You may have heard of total quality management (TQM) or Six Sigma, and similar philosophies⁷ that foster a culture of continuous process improvement. It is this culture that ultimately leads to more effective approaches to software engineering. The bedrock that supports software engineering is a quality focus.

软件工程的基础是过程层。软件工程过程是将技术层粘合在一起的粘合剂，能够合理、及时地开发计算机软件。流程定义了为有效交付软件工程技术而必须建立的框架。软件过程构成了软件项目管理控制的基础，并建立了应用技术方法、生成工作产品（模型、文档、数据、报告、表格等）、建立里程碑、确保质量、并且变革得到妥善管理。

The foundation for software engineering is the process layer. The software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework that must be established for effective delivery of software engineering technology. The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed.

软件工程方法提供了构建软件的技术指南。方法涵盖广泛的任务，包括沟通、需求分析、设计建模、程序构建、测试和支持。软件工程方法依赖于一组控制技术每个领域的基本原则，包括建模活动和其他描述性技术。

Software engineering methods provide the technical how-to’s for building software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques.

软件工程工具为过程和方法提供自动化或半自动化支持。当工具被集成，使得一种工具创建的信息可以被另一种工具使用时，就建立了一个支持软件开发的系统，称为计算机辅助软件工程。

Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.

1.3 软件流程

1.3 The Software Process

流程是创建某些工作产品时执行的活动、操作和任务的集合。一项活动致力于实现一个广泛的目标（例如，与利益相关者的沟通），并且无论应用领域、项目的规模、工作的复杂性或应用软件工程的严格程度如何，都可以应用该活动。一个动作（例如，架构设计）包含一组产生主要工作产品（例如，架构模型）的任务。任务侧重于一个小但定义明确的目标（例如，进行单元测试），该目标会产生切实的结果。

A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which software engineering is to be applied. An action (e.g., architectural design) encompasses a set of tasks that produce a major work product (e.g., an architectural model). A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.

第10页在软件工程的背景下，过程并不是如何构建计算机软件的严格规定。相反，它是一种适应性强的方法，使工作人员（软件团队）能够挑选和选择适当的工作操作和任务集。我们的目的始终是及时、高质量地交付软件，以满足赞助者和使用者的需求。

Page 10In the context of software engineering, a process is not a rigid prescription for how to build computer software. Rather, it is an adaptable approach that enables the people doing the work (the software team) to pick and choose the appropriate set of work actions and tasks. The intent is always to deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it.

1.3.1 流程框架

1.3.1 The Process Framework

过程框架通过识别适用于所有软件项目（无论其规模或复杂性）的少量框架活动，为完整的软件工程过程奠定了基础。此外，流程框架包含一组适用于整个软件流程的伞式活动。软件工程的通用过程框架包含五项活动：

A process framework establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. In addition, the process framework encompasses a set of umbrella activities that are applicable across the entire software process. A generic process framework for software engineering encompasses five activities:

沟通。在开始任何技术工作之前，与客户（和其他利益相关者）的沟通和协作至关重要。⁸目的是了解利益相关者的项目目标并收集有助于定义软件特性和功能的需求。

Communication. Before any technical work can commence, it is critically important to communicate and collaborate with the customer (and other stakeholders).⁸ The intent is to understand stakeholders’ objectives for the project and to gather requirements that help define software features and functions.

规划。如果有地图，任何复杂的旅程都可以简化。软件项目是一个复杂的旅程，规划活动创建一个“地图”，帮助指导团队完成旅程。该地图（称为软件项目计划）通过描述要执行的技术任务、可能的风险、需要的资源、要生产的工作产品和工作时间表来定义软件工程工作。

Planning. Any complicated journey can be simplified if a map exists. A software project is a complicated journey, and the planning activity creates a “map” that helps guide the team as it makes the journey. The map—called a software project plan—defines the software engineering work by describing the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule.

造型。无论您是园林设计师、桥梁建造者、航空工程师、木匠还是建筑师，您每天都会与模型打交道。您创建事物的“草图”，以便了解整体情况——它的架构是什么样子、各组成部分如何组合在一起，以及许多其他特征。如果需要，您可以将草图细化为越来越详细，以便更好地理解问题以及如何解决它。软件工程师通过创建模型来完成同样的事情，以更好地理解软件需求和实现这些需求的设计。

Modeling. Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a carpenter, or an architect, you work with models every day. You create a “sketch” of the thing so that you’ll understand the big picture—what it will look like architecturally, how the constituent parts fit together, and many other characteristics. If required, you refine the sketch into greater and greater detail in an effort to better understand the problem and how you’re going to solve it. A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements.

建造。你设计的东西必须被建造。此活动结合了代码生成（手动或自动）和发现代码中的错误所需的测试。

Construction. What you design must be built. This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.

第11页部署。软件（作为完整的实体或部分完成的增量）交付给客户，客户评估交付的产品并根据评估提供反馈。

Page 11Deployment. The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation.

这五个通用框架活动可以在开发小型、简单的程序时使用；创建网络应用程序；以及大型、复杂的基于计算机的系统的工程。在每种情况下，软件过程的细节将有很大不同，但框架活动保持不变。

These five generic framework activities can be used during the development of small, simple programs; the creation of Web applications; and for the engineering of large, complex computer-based systems. The details of the software process will be quite different in each case, but the framework activities remain the same.

对于许多软件项目，框架活动随着项目的进展而迭代应用。也就是说，沟通、规划、建模、构建和部署是通过多次项目迭代而重复应用的。每次迭代都会产生一个软件增量，为利益相关者提供整体软件特性和功能的子集。随着每一个增量的产生，软件变得越来越完整。

For many software projects, framework activities are applied iteratively as a project progresses. That is, communication, planning, modeling, construction, and deployment are applied repeatedly through a number of project iterations. Each iteration produces a software increment that provides stakeholders with a subset of overall software features and functionality. As each increment is produced, the software becomes more and more complete.

1.3.2 伞式活动

1.3.2 Umbrella Activities

软件工程过程框架活动由许多伞式活动补充。一般来说，伞式活动应用于整个软件项目，帮助软件团队管理和控制进度、质量、变更和风险。典型的保护伞活动包括：

Software engineering process framework activities are complemented by a number of umbrella activities. In general, umbrella activities are applied throughout a software project and help a software team manage and control progress, quality, change, and risk. Typical umbrella activities include:

软件项目跟踪和控制。允许软件团队根据项目计划评估进度，并采取任何必要的措施来维持进度。

Software project tracking and control. Allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule.

风险管理。评估可能影响项目结果或产品质量的风险。

Risk management. Assesses risks that may affect the outcome of the project or the quality of the product.

软件质量保证。定义并开展确保软件质量所需的活动。

Software quality assurance. Defines and conducts the activities required to ensure software quality.

技术审查。评估软件工程工作产品，努力在错误传播到下一个活动之前发现并消除错误。

Technical reviews. Assess software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity.

测量。定义并收集流程、项目和产品衡量标准，帮助团队交付满足利益相关者需求的软件；可以与所有其他框架和伞式活动结合使用。

Measurement. Defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities.

软件配置管理。管理整个软件流程中变更的影响。

Software configuration management. Manages the effects of change throughout the software process.

可重用性管理。定义工作产品重用（包括软件组件）的标准并建立实现可重用组件的机制。

Reusability management. Defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components.

工作产品准备和生产。包含创建工作产品（例如模型、文档、日志、表单和列表）所需的活动。

Work product preparation and production. Encompasses the activities required to create work products such as models, documents, logs, forms, and lists.

本书后面将详细讨论每项伞式活动。

Each of these umbrella activities is discussed in detail later in this book.

1.3.3 工艺适应

1.3.3 Process Adaptation

在本节前面，我们注意到软件工程过程并不是软件团队必须教条地遵循的严格规定。相反，它应该是敏捷的和适应性强的（针对问题、项目、团队和组织文化）。因此，一个项目采用的流程可能与另一项目采用的流程显着不同。其中差异包括：第12页

Previously in this section, we noted that the software engineering process is not a rigid prescription that must be followed dogmatically by a software team. Rather, it should be agile and adaptable (to the problem, to the project, to the team, and to the organizational culture). Therefore, a process adopted for one project might be significantly different than a process adopted for another project. Among the differences are:Page 12

• 活动、行动和任务的总体流程以及它们之间的相互依赖性

• Overall flow of activities, actions, and tasks and the interdependencies among them

• 每个框架活动中定义操作和任务的程度

• Degree to which actions and tasks are defined within each framework activity

• 工作产品被识别和需要的程度

• Degree to which work products are identified and required

• 质量保证活动的实施方式

• Manner in which quality assurance activities are applied

• 项目跟踪和控制活动的应用方式

• Manner in which project tracking and control activities are applied

• 描述过程的总体详细程度和严谨程度

• Overall degree of detail and rigor with which the process is described

• 客户和其他利益相关者参与项目的程度

• Degree to which the customer and other stakeholders are involved with the project

• 给予软件团队的自主权

• Level of autonomy given to the software team

• 团队组织和角色的规定程度

• Degree to which team organization and roles are prescribed

在本书的第一部分中，我们相当详细地研究了软件过程。

In Part One of this book, we examine software process in considerable detail.

1.4 软件工程实践

1.4 Software Engineering Practice

在1.3 节中，我们介绍了一个通用软件过程模型，该模型由一组建立软件工程实践框架的活动组成。通用框架活动（通信、规划、建模、构建和部署）和伞式活动为软件工程工作建立了框架架构。但是软件工程的实践如何适应呢？在接下来的部分中，您将对适用于框架活动的通用概念和原则有基本的了解。⁹

In Section 1.3, we introduced a generic software process model composed of a set of activities that establish a framework for software engineering practice. Generic framework activities—communication, planning, modeling, construction, and deployment—and umbrella activities establish a skeleton architecture for software engineering work. But how does the practice of software engineering fit in? In the sections that follow, you’ll gain a basic understanding of the generic concepts and principles that apply to framework activities.⁹

1.4.1 实践的本质

1.4.1 The Essence of Practice

在现代计算机出现之前写的经典著作《How to Solve It》中，George Polya [Pol45] 概述了问题解决的本质，进而概述了软件工程实践的本质：

In the classic book How to Solve It, written before modern computers existed, George Polya [Pol45] outlined the essence of problem solving, and consequently, the essence of software engineering practice:

1. 了解问题（沟通和分析）。

2. Understand the problem (communication and analysis).

3. 规划解决方案（建模和软件设计）。

4. Plan a solution (modeling and software design).

5. 执行计划（代码生成）。

6. Carry out the plan (code generation).

7. 检查结果的准确性（测试和质量保证）。

8. Examine the result for accuracy (testing and quality assurance).

在软件工程的背景下，这些常识性步骤引出了一系列基本问题[改编自 Pol45]：

In the context of software engineering, these commonsense steps lead to a series of essential questions [adapted from Pol45]:

了解问题。有时很难承认，但当我们遇到问题时，我们大多数人都会感到傲慢。我们听了几秒钟，然后想，哦，是的，我明白了，让我们继续解决这个问题吧。不幸的是，理解并不总是那么容易。值得花一点时间回答一些简单的问题：第13页

Understand the Problem. It’s sometimes difficult to admit, but most of us suffer from hubris when we’re presented with a problem. We listen for a few seconds and then think, Oh yeah, I understand, let’s get on with solving this thing. Unfortunately, understanding isn’t always that easy. It’s worth spending a little time answering a few simple questions:Page 13

• 问题的解决与谁有利害关系？也就是说，利益相关者是谁？

• Who has a stake in the solution to the problem? That is, who are the stakeholders?

• 有哪些未知数？正确解决问题需要哪些数据、功能和特征？

• What are the unknowns? What data, functions, and features are required to properly solve the problem?

• 问题可以划分吗？是否可以表示更容易理解的较小问题？

• Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand?

• 问题可以用图形表示吗？可以创建分析模型吗？

• Can the problem be represented graphically? Can an analysis model be created?

规划解决方案。现在您了解了问题（或者您认为是这样），并且迫不及待地开始编码。在开始之前，先放慢速度并做一些设计：

Plan the Solution. Now you understand the problem (or so you think), and you can’t wait to begin coding. Before you do, slow down just a bit and do a little design:

• 您以前见过类似的问题吗？潜在解决方案中是否存在可识别的模式？是否有现有软件可以实现所需的数据、功能和特性？

• Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required?

• 有类似的问题解决了吗？如果是这样，解决方案的元素可以重复使用吗？

• Has a similar problem been solved? If so, are elements of the solution reusable?

• 子问题可以定义吗？如果是这样，子问题的解决方案是否显而易见？

• Can subproblems be defined? If so, are solutions readily apparent for the subproblems?

• 您能否以能够有效实施的方式提出解决方案？可以创建设计模型吗？

• Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?

执行计划。您创建的设计可作为您想要构建的系统的路线图。可能会有意想不到的弯路，也可能边走边发现更好的路线，但“计划”会让你继续前行而不会迷路。

Carry Out the Plan. The design you’ve created serves as a road map for the system you want to build. There may be unexpected detours, and it’s possible that you’ll discover an even better route as you go, but the “plan” will allow you to proceed without getting lost.

• 解决方案是否符合计划？源代码是否可以追溯到设计模型？

• Does the solution conform to the plan? Is source code traceable to the design model?

• 解决方案的每个组成部分是否都被证明是正确的？设计和代码是否经过审查，或者更好的是，正确性证明是否已应用于算法？

• Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to the algorithm?

检查结果。您不能确定您的解决方案是否完美，但您可以确定您已经设计了足够数量的测试来发现尽可能多的错误。

Examine the Result. You can’t be sure that your solution is perfect, but you can be sure that you’ve designed a sufficient number of tests to uncover as many errors as possible.

• 是否可以测试解决方案的每个组成部分？是否实施了合理的测试策略？

• Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?

• 该解决方案产生的结果是否符合所需的数据、功能和特性？该软件是否已根据所有利益相关者的要求进行了验证？

• Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements?

这种方法大部分都是常识，这一点您应该不会感到惊讶。事实上，可以合理地说，软件工程的常识性方法永远不会让您误入歧途。

It shouldn’t surprise you that much of this approach is common sense. In fact, it’s reasonable to state that a commonsense approach to software engineering will never lead you astray.

第14页

Page 14

1.4.2 一般原则

1.4.2 General Principles

字典将“原则”一词定义为“思想体系中所需的重要基本法则或假设”。在本书中，我们将讨论许多不同抽象级别的原则。一些关注软件工程作为一个整体，另一些关注特定的通用框架活动（例如，通信），还有一些关注软件工程操作（例如，架构设计）或技术任务（例如，创建使用场景）。无论其关注程度如何，原则都可以帮助您建立扎实的软件工程实践的思维模式。因此它们很重要。

The dictionary defines the word principle as “an important underlying law or assumption required in a system of thought.” Throughout this book we’ll discuss principles at many different levels of abstraction. Some focus on software engineering as a whole, others consider a specific generic framework activity (e.g., communication), and still others focus on software engineering actions (e.g., architectural design) or technical tasks (e.g., creating a usage scenario). Regardless of their level of focus, principles help you establish a mind-set for solid software engineering practice. They are important for that reason.

David Hooker [Hoo96] 提出了七个原则，重点关注整个软件工程实践。它们转载于以下段落：¹⁰

David Hooker [Hoo96] has proposed seven principles that focus on software engineering practice as a whole. They are reproduced in the following paragraphs:¹⁰

第一条原则： 一切存在的原因

The First Principle: The Reason It All Exists

软件系统存在的原因只有一个：为用户提供价值。所有决定都应考虑到这一点。在指定系统要求之前，在注意某个系统功能之前，在确定硬件平台或开发流程之前，先问自己一些问题，例如：“这是否为系统增加了真正的价值？” 如果答案是否定的，请不要这样做。所有其他原则都支持这一原则。

A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: “Does this add real value to the system?” If the answer is no, don’t do it. All other principles support this one.

第二条原则： KISS（保持简单，愚蠢！）

The Second Principle: KISS (Keep It Simple, Stupid!)

在任何设计工作中都需要考虑许多因素。所有的设计都应该尽可能简单，但又不能简单。这有助于拥有更容易理解和维护的系统。这并不是说应该以简单的名义放弃功能。事实上，越优雅的设计通常越简单。简单并不意味着“快速而肮脏”。通常需要进行大量思考并进行多次迭代才能简化设计。回报是软件更易于维护且不易出错。

There are many factors to consider in any design effort. All design should be as simple as possible, but no simpler. This facilitates having a more easily understood and easily maintained system. This is not to say that features should be discarded in the name of simplicity. Indeed, the more elegant designs are usually the simpler ones. Simple does not mean “quick and dirty.” It often takes a lot of thought and work over multiple iterations to simplify the design. The payoff is software that is more maintainable and less error-prone.

第三条原则： 保持愿景

The Third Principle: Maintain the Vision

清晰的愿景对于软件项目的成功至关重要。如果没有概念完整性，系统就有可能成为由不兼容的设计拼凑而成，并由错误类型的螺丝固定在一起。。。损害软件系统的架构愿景会削弱甚至最终破坏设计良好的系统。拥有一位能够保持愿景并强制执行合规性的授权架构师有助于确保软件项目非常成功。

A clear vision is essential to the success of a software project. Without conceptual integrity, a system threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws . . . Compromising the architectural vision of a software system weakens and will eventually break even the well-designed systems. Having an empowered architect who can hold the vision and enforce compliance helps ensure a very successful software project.

第四条原则： 你生产什么，别人就会消费什么

The Fourth Principle: What You Produce, Others Will Consume

始终指定、设计、记录和实施，知道其他人必须理解您在做什么。任何软件开发产品的受众都可能很大。着眼于用户进行指定。设计时，牢记实施者。为那些必须维护和扩展系统的人编写代码。有人可能必须调试您编写的代码，这使他们成为您代码的用户。让他们的工作变得更轻松可以增加系统的价值。

Always specify, design, document, and implement knowing someone else will have to understand what you are doing. The audience for any product of software development is potentially large. Specify with an eye to the users. Design, keeping the implementers in mind. Code with concern for those that must maintain and extend the system. Someone may have to debug the code you write, and that makes them a user of your code. Making their job easier adds value to the system.

第15页

Page 15

第五条原则： 对未来持开放态度

The Fifth Principle: Be Open to the Future

在当今的计算环境中，规格会随时发生变化，硬件平台在几个月后就会过时，软件生命周期通常以月而不是几年来衡量。然而，真正的“工业强度”软件系统必须持续更长时间。为此，系统必须做好适应这些和其他变化的准备。成功做到这一点的系统从一开始就是这样设计的。永远不要让自己陷入困境。始终询问“如果”，并通过创建解决一般问题（而不仅仅是特定问题）的系统来为所有可能的答案做好准备。¹¹

In today’s computing environments, where specifications change on a moment’s notice and hardware platforms are obsolete just a few months old, software lifetimes are typically measured in months instead of years. However, true “industrial-strength” software systems must endure far longer. To do this, systems must be ready to adapt to these and other changes. Systems that do this successfully have been designed this way from the start. Never design yourself into a corner. Always ask “what if,” and prepare for all possible answers by creating systems that solve the general problem, not just the specific one.¹¹

第六条原则： 提前计划重用

The Sixth Principle: Plan Ahead for Reuse

重复使用可以节省时间和精力。¹²实现高水平的重用可以说是开发软件系统中最难实现的目标。代码和设计的重用已被认为是使用面向对象技术的主要好处。然而，这项投资的回报并不是自动的。提前规划重用可以降低成本并增加可重用组件及其所包含的系统的价值。

Reuse saves time and effort.¹² Achieving a high level of reuse is arguably the hardest goal to accomplish in developing a software system. The reuse of code and designs has been proclaimed as a major benefit of using object-oriented technologies. However, the return on this investment is not automatic. Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated.

第七条原则： 思考！

The Seventh Principle: Think!

最后一条原则可能是最容易被忽视的。在行动之前进行清晰、完整的思考几乎总是会产生更好的结果。当你思考某件事时，你更有可能做对。您还可以获得有关如何再次正确行事的知识。如果你确实思考过某件事但仍然做错了，那么它就会成为一次宝贵的经历。思考的一个副作用是学会识别你不知道的东西，此时你可以研究答案。当清晰的思想进入系统时，价值就会显现出来。应用前六个原则需要深入思考，而潜在的回报是巨大的。

This last principle is probably the most overlooked. Placing clear, complete thought before action almost always produces better results. When you think about something, you are more likely to do it right. You also gain knowledge about how to do it right again. If you do think about something and still do it wrong, it becomes a valuable experience. A side effect of thinking is learning to recognize when you don’t know something, at which point you can research the answer. When clear thought has gone into a system, value comes out. Applying the first six principles requires intense thought, for which the potential rewards are enormous.

如果每个软件工程师和每个软件团队都简单地遵循胡克的七个原则，那么我们在构建复杂的基于计算机的系统时遇到的许多困难都将被消除。

If every software engineer and every software team simply followed Hooker’s seven principles, many of the difficulties we experience in building complex computer-based systems would be eliminated.

1.5 一切是如何开始的

1.5 How It All Starts

每个软件项目都是由某些业务需求促成的——需要纠正现有应用程序中的缺陷；需要使“遗留系统”适应不断变化的业务环境；需要扩展现有应用程序的功能和特性；或需要创建新产品、服务或系统。

Every software project is precipitated by some business need—the need to correct a defect in an existing application; the need to adapt a “legacy system” to a changing business environment; the need to extend the functions and features of an existing application; or the need to create a new product, service, or system.

第16页在软件项目开始时，业务需求通常作为简单对话的一部分非正式地表达。侧边栏中呈现的对话是典型的。

Page 16At the beginning of a software project, the business need is often expressed informally as part of a simple conversation. The conversation presented in the sidebar is typical.

除了顺便提及之外，谈话中几乎没有提及软件。然而，软件将决定SafeHome产品线的成败。只有SafeHome软件成功，工程工作才会成功。只有当产品中嵌入的软件正确满足客户（尚未明确）的需求时，市场才会接受该产品。我们将在接下来的许多章节中跟踪SafeHome软件工程的进展。

With the exception of a passing reference, software was hardly mentioned as part of the conversation. And yet, software will make or break the SafeHome product line. The engineering effort will succeed only if SafeHome software succeeds. The market will accept the product only if the software embedded within it properly meets the customer’s (as yet unstated) needs. We’ll follow the progression of SafeHome software engineering in many of the chapters that follow.

第17页

Page 17

1.6 总结

1.6 Summary

软件是基于计算机的系统和产品发展的关键要素，也是世界舞台上最重要的技术之一。在过去的 60 年里，软件已经从专门的问题解决和信息分析工具发展成为一个独立的行业。然而，我们仍然难以在预算范围内按时开发高质量的软件。

Software is the key element in the evolution of computer-based systems and products and one of the most important technologies on the world stage. Over the past 60 years, software has evolved from a specialized problem-solving and information analysis tool to an industry in itself. Yet we still have trouble developing high-quality software on time and within budget.

软件（程序、数据和描述性信息）涉及广泛的技术和应用领域。遗留软件继续给那些必须维护它的人带来特殊的挑战。

Software—programs, data, and descriptive information—addresses a wide array of technology and application areas. Legacy software continues to present special challenges to those who must maintain it.

软件工程包含能够及时、高质量地构建复杂的基于计算机的系统的过程、方法和工具。软件过程包含五个框架活动——沟通、规划、建模、构建和部署——适用于所有软件项目。软件工程实践是遵循一组核心原则的解决问题的活动。随着您对软件工程的了解越来越多，您将开始理解为什么在开始任何软件项目时应考虑这些原则。

Software engineering encompasses process, methods, and tools that enable complex computer-based systems to be built in a timely manner with quality. The software process incorporates five framework activities—communication, planning, modeling, construction, and deployment—that are applicable to all software projects. Software engineering practice is a problem-solving activity that follows a set of core principles. As you learn more about software engineering, you’ll begin to understand why these principles should be considered when beginning any software project.

问题与思考点

Problems and Points to Ponder

1.1. 提供至少五个额外示例，说明意外后果法则如何适用于计算机软件。

1.1. Provide at least five additional examples of how the law of unintended consequences applies to computer software.

1.2. 提供一些例子（正面和负面）来表明软件对我们社会的影响。

1.2. Provide a number of examples (both positive and negative) that indicate the impact of software on our society.

1.3. 针对第 1.1 节开头提出的五个问题制定您自己的答案。与你的同学讨论它们。

1.3. Develop your own answers to the five questions asked at the beginning of Section 1.1. Discuss them with your fellow students.

1.4. 许多现代应用程序经常发生变化——在将它们呈现给最终用户之前，然后在第一个版本投入使用之后。提出几种构建软件的方法，以阻止因变化而恶化。

1.4. Many modern applications change frequently—before they are presented to the end user and then after the first version has been put into use. Suggest a few ways to build software to stop deterioration due to change.

1.5. 考虑第 1.1.2 节中介绍的七个软件类别。您认为相同的软件工程方法可以应用于每种方法吗？解释你的答案。

1.5. Consider the seven software categories presented in Section 1.1.2. Do you think that the same approach to software engineering can be applied for each? Explain your answer.

1.6. 随着软件变得越来越普遍，公众面临的风险（由于错误的程序）变得越来越重要。设计一个世界末日但现实的场景，其中计算机程序的失败可能会造成巨大的经济或人类伤害。

1.6. As software becomes more pervasive, risks to the public (due to faulty programs) become an increasingly significant concern. Develop a doomsday but realistic scenario in which the failure of a computer program could do great harm, either economic or human.

1.7. 用你自己的话描述一个流程框架。当我们说框架活动适用于所有项目时，这是否意味着相同的工作任务适用于所有项目，无论其规模和复杂程度如何？解释。

1.7. Describe a process framework in your own words. When we say that framework activities are applicable to all projects, does this mean that the same work tasks are applied for all projects, regardless of size and complexity? Explain.

1.8. 伞形活动发生在整个软件过程中。您认为它们是均匀地应用于整个流程，还是集中在一项或多项框架活动中？

1.8. Umbrella activities occur throughout the software process. Do you think they are applied evenly across the process, or are some concentrated in one or more framework activities?

第19页

Page 19

第20页

Page 20

第21页

Page 21

2.1 通用过程模型

2.1 A Generic Process Model

在第一章中，流程被定义为创建某些工作产品时执行的活动、操作和任务的集合。这些活动、操作和任务中的每一项都驻留在一个框架或模型中，该框架或模型定义了它们与流程以及彼此之间的关系。

In Chapter 1, a process was defined as a collection of activities, actions, and tasks that are performed when some work product is to be created. Each of these activities, actions, and tasks resides within a framework or model that defines their relationship with the process and with one another.

软件流程如图 2.1所示。参考该图，每个框架活动都由一组软件工程操作填充。每个软件工程操作都由任务集定义，该任务集标识要完成的工作任务、将生成的工作产品、所需的质量保证点以及将用于指示进度的里程碑。

The software process is represented schematically in Figure 2.1. Referring to the figure, each framework activity is populated by a set of software engineering actions. Each software engineering action is defined by a task set that identifies the work tasks that are to be completed, the work products that will be produced, the quality assurance points that will be required, and the milestones that will be used to indicate progress.

正如我们在第 1 章中讨论的，软件工程的通用过程框架定义了五个框架活动——通信、规划、建模、构建和部署。此外，在整个过程中还应用了一系列伞式活动——项目跟踪和控制、风险管理、质量保证、配置管理、技术审查等。第22页

As we discussed in Chapter 1, a generic process framework for software engineering defines five framework activities—communication, planning, modeling, construction, and deployment. In addition, a set of umbrella activities—project tracking and control, risk management, quality assurance, configuration management, technical reviews, and others—are applied throughout the process.Page 22

您应该注意到，软件过程的一个重要方面尚未讨论。这个方面（称为流程）描述了框架活动以及每个框架活动中发生的操作和任务如何按照顺序和时间进行组织。如图 2.2所示。

You should note that one important aspect of the software process has not been discussed yet. This aspect—called process flow—describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time. It is illustrated in Figure 2.2.

线性流程按顺序执行五个框架活动中的每一个，从通信开始，到部署结束（图 2.2a）。迭代流程会重复一个或多个活动，然后再进行下一个活动（图 2.2b）。演化过程流以“循环”方式执行活动。通过五个活动的每个电路都会产生一个更完整的软件版本（图 2.2c）。并行流程（图2.2d）与其他活动并行执行一个或多个活动（例如，软件一方面的建模可能与软件另一方面的构建并行执行）。

A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment (Figure 2.2a). An iterative process flow repeats one or more of the activities before proceeding to the next (Figure 2.2b). An evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of the software (Figure 2.2c). A parallel process flow (Figure 2.2d) executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software might be executed in parallel with construction of another aspect of the software).

第23页

Page 23

2.2 定义框架活动

2.2 Defining a Framework Activity

尽管我们在第 1 章中描述了五个框架活动并提供了每个活动的基本定义，但软件团队在能够作为软件流程的一部分正确执行这些活动中的任何一个之前，将需要更多的信息。因此，您面临一个关键问题：考虑到要解决的问题的性质、工作人员的特征以及赞助该项目的利益相关者，哪些行动适合框架活动？

Although we have described five framework activities and provided a basic definition of each in Chapter 1, a software team would need significantly more information before it could properly execute any one of these activities as part of the software process. Therefore, you are faced with a key question: What actions are appropriate for a framework activity, given the nature of the problem to be solved, the characteristics of the people doing the work, and the stakeholders who are sponsoring the project?

对于由一个人（在远程位置）请求且要求简单、直接的小型软件项目，通信活动可能只不过是与适当的利益相关者进行电话或电子邮件。因此，唯一必要的操作是电话交谈，并且该操作包含的工作任务（任务集）是：

For a small software project requested by one person (at a remote location) with simple, straightforward requirements, the communication activity might encompass little more than a phone call or e-mail with the appropriate stakeholder. Therefore, the only necessary action is phone conversation, and the work tasks (the task set) that this action encompasses are:

1. 通过电话与利益相关者取得联系。

2. Make contact with stakeholder via telephone.

3. 讨论需求并制定注释。

4. Discuss requirements and develop notes.

5. 将笔记整理成简短的书面要求说明。

6. Organize notes into a brief written statement of requirements.

7. 通过电子邮件发送给利益相关者以供审核和批准。

8. E-mail to stakeholder for review and approval.

如果项目相当复杂，有很多利益相关者，每个利益相关者都有一组不同的（有时是相互冲突的）需求，那么沟通活动可能有六种不同的操作：启动、启发、阐述、谈判、规范和验证。这些软件工程操作中的每一个都可能有许多工作任务，并且在某些情况下有许多不同的工作产品。

If the project was considerably more complex with lots of stakeholders, each with a different set of (sometimes conflicting) requirements, the communication activity might have six distinct actions: inception, elicitation, elaboration, negotiation, specification, and validation. Each of these software engineering actions might have many work tasks and in some cases a number of distinct work products.

2.3 识别任务集

2.3 Identifying a Task Set

再次参考图 2.1，每个软件工程操作（例如，启发、与通信活动相关的操作）可以由许多不同的任务集来表示- 每个任务集都是软件工程工作任务、相关工作产品、质量保证点的集合和项目里程碑。不同的项目需要不同的任务集。您应该选择最适合项目需求和团队特点的任务集。这意味着软件工程行动应该适应软件项目的特定需求和项目团队的特征。第24页

Referring again to Figure 2.1, each software engineering action (e.g., elicitation, an action associated with the communication activity) can be represented by a number of different task sets—each a collection of software engineering work tasks, related work products, quality assurance points, and project milestones. Different projects demand different task sets. You should choose a task set that best accommodates the needs of the project and the characteristics of your team. This implies that a software engineering action should be adapted to the specific needs of the software project and the characteristics of the project team.Page 24

2.4 过程评估和改进

2.4 Process Assessment and Improvement

软件过程的存在并不能保证软件能够按时交付、能够满足客户的需求或者能够展现出导致长期质量特征的技术特征（第15章）。过程模式必须与可靠的软件工程实践相结合（本书的第二部分）。此外，还可以评估流程本身，以确保其满足一组基本流程标准，这些标准已被证明对于成功的软件工程至关重要。¹

The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer’s needs, or that it will exhibit the technical characteristics that will lead to long-term quality characteristics (Chapter 15). Process patterns must be coupled with solid software engineering practice (Part Two of this book). In addition, the process itself can be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for successful software engineering.¹

大多数工程师当前的想法是，应使用数字测量或软件分析（指标）来评估软件流程和活动。这第25页您在实现有效软件流程的过程中所取得的进展将定义您可以以有意义的方式衡量改进的程度。第 17 章介绍了使用软件过程度量来评估过程质量。第 28 章对过程评估和改进方法进行了更详细的讨论。

The current thinking among most engineers is that software processes and activities should be assessed using numeric measures or software analytics (metrics). The Page 25progress you have made in a journey toward an effective software process will define the degree to which you can measure improvement in a meaningful way. The use of software process metrics to assess process quality is introduced in Chapter 17. A more detailed discussion of process assessment and improvement methods is presented in Chapter 28.

2.5 规定的过程模型

2.5 Prescriptive Process Models

规范性流程模型定义了一组预定义的流程元素和可预测的流程工作流程。规范性过程模型²力求软件开发的结构和顺序。活动和任务按照既定的进度指南顺序进行。但是规范性模型是否适合在变化中蓬勃发展的软件世界？如果我们拒绝传统的流程​​模型（以及它们所暗示的顺序）并用结构化程度较低的模型替代它们，那么我们是否就无法在软件工作中实现协调性和连贯性？

Prescriptive process models define a predefined set of process elements and a predictable process work flow. Prescriptive process models² strive for structure and order in software development. Activities and tasks occur sequentially with defined guidelines for progress. But are prescriptive models appropriate for a software world that thrives on change? If we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

这些问题没有简单的答案，但软件工程师有其他选择。在接下来的部分中，我们概述了规范性流程方法，其中顺序和项目一致性是主要问题。我们称它们为“规定性”，因为它们规定了一组流程元素——框架活动、软件工程操作、任务、工作产品、质量保证和每个项目的变更控制机制。每个过程模型还规定了一个过程流（也称为工作流），即过程元素相互关联的方式。

There are no easy answers to these questions, but there are alternatives available to software engineers. In the sections that follow, we provide an overview of the prescriptive process approach in which order and project consistency are dominant issues. We call them “prescriptive” because they prescribe a set of process elements—framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms for each project. Each process model also prescribes a process flow (also called a work flow)—that is, the manner in which the process elements are interrelated to one another.

所有软件过程模型都可以容纳第 1 章中描述的通用框架活动，但每个模型对这些活动应用不同的重点，并定义以不同方式调用每个框架活动（以及软件工程操作和任务）的过程流。在第 3 章和第 4章中，我们将讨论软件工程实践，这些实践努力适应许多软件项目开发过程中不可避免的变化。

All software process models can accommodate the generic framework activities described in Chapter 1, but each applies a different emphasis to these activities and defines a process flow that invokes each framework activity (as well as software engineering actions and tasks) in a different manner. In Chapters 3 and 4 we will discuss software engineering practices that strive to accommodate the changes that are inevitable during the development of many software projects.

2.5.1 瀑布模型

2.5.1 The Waterfall Model

有时，问题的需求可以很好地理解——工作以相当线性的方式从通信流向部署。当必须对现有系统进行明确的调整或增强时（例如，对会计软件进行调整，因为它需要适应强制性政府法规的变化），有时会遇到这种情况。它也可能发生在有限数量的新开发工作中，但前提是需求已明确定义且相当稳定。

There are times when the requirements for a problem are well understood—when work flows from communication through deployment in a reasonably linear fashion. This situation is sometimes encountered when well-defined adaptations or enhancements to an existing system must be made (e.g., an adaptation to accounting software because it needs to accommodate changes to mandated government regulations). It may also occur in a limited number of new development efforts, but only when requirements are well defined and reasonably stable.

瀑布模型，有时称为线性顺序模型，提出了一种系统的、顺序的软件开发方法³，该方法从客户的需求规范开始，然后通过规划、建模、构建和部署进行，最终为已完成的软件提供持续支持（图2.3）。第26页

The waterfall model, sometimes called the linear sequential model, suggests a systematic, sequential approach³ to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software (Figure 2.3).Page 26

瀑布模型是软件工程最古老的范例。然而，在过去的五年里，对这一流程模型的批评甚至导致了热心支持者对其有效性的质疑。应用瀑布模型时有时会遇到的问题包括：

The waterfall model is the oldest paradigm for software engineering. However, over the past five decades, criticism of this process model has caused even ardent supporters to question its efficacy. Among the problems that are sometimes encountered when the waterfall model is applied are:

1. 实际项目很少遵循模型提出的顺序工作流程。

2. Real projects rarely follow the sequential work flow that the model proposes.

3. 客户通常很难在大多数项目开始时明确说明所有要求。

4. It is often difficult for the customer to state all requirements explicitly at the beginning of most projects.

5. 客户必须有耐心，因为直到项目时间跨度后期才会提供程序的工作版本。

6. The customer must have patience because a working version of the program(s) will not be available until late in the project time span.

7. 在审查工作计划之前，可能无法发现重大错误。

8. Major blunders may not be detected until the working program is reviewed.

如今，软件工作节奏很快，并且面临着永无休止的变化（特性、功能和信息内容）。瀑布模型通常不适合此类工作。

Today, software work is fast paced and subject to a never-ending stream of changes (to features, functions, and information content). The waterfall model is often inappropriate for such work.

2.5.2 原型流程模型

2.5.2 Prototyping Process Model

通常，客户定义了一组软件的总体目标，但没有确定功能和特性的详细要求。在其他情况下，开发人员可能不确定算法的效率、操作系统的适应性或人机交互应采取的形式。在这些以及许多其他情况下，原型设计范式可能提供最佳方法。

Often, a customer defines a set of general objectives for software but does not identify detailed requirements for functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach.

虽然原型设计可以用作独立的流程模型，但它更常用作一种可以在本章提到的任何一个流程模型的上下文中实现的技术。无论以何种方式应用，原型范式都可以帮助您和其他利益相关者更好地理解当需求模糊时要构建什么。第27页

Although prototyping can be used as a stand-alone process model, it is more commonly used as a technique that can be implemented within the context of any one of the process models noted in this chapter. Regardless of the manner in which it is applied, the prototyping paradigm assists you and other stakeholders to better understand what is to be built when requirements are fuzzy.Page 27

例如，使用增量原型开发的健身应用程序可能会提供将手机与健身设备同步并显示当前数据所需的基本用户界面屏幕；第二个原型可能包含设定目标和在云上存储健身设备数据的能力，根据客户的反馈创建和修改用户界面屏幕；第三个原型可能包括社交媒体集成，允许用户设定健身目标并与一群朋友分享目标进度。

For example, a fitness app developed using incremental prototypes might deliver the basic user interface screens needed to sync a mobile phone with the fitness device and display the current data; the ability to set goals and store the fitness device data on the cloud might be included in the second prototype, creating and modifying the user interface screens based on customers feedback; and a third prototype might include social media integration to allow users to set fitness goals and share progress toward them with a set of friends.

原型设计范式（图 2.4）从沟通开始。您与其他利益相关者会面，定义软件的总体目标，确定已知的需求，并概述必须进一步定义的领域。快速规划原型迭代，并进行建模（以“快速设计”的形式）。快速设计侧重于最终用户可见的软件方面的表示（例如，人机界面布局或输出显示格式）。快速设计导致了原型的构建。原型由利益相关者部署和评估，利益相关者提供用于进一步细化需求的反馈。当原型被调整以满足不同利益相关者的需求时，就会发生迭代，同时使您能够更好地理解需要做什么。

The prototyping paradigm (Figure 2.4) begins with communication. You meet with other stakeholders to define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A prototyping iteration is planned quickly, and modeling (in the form of a “quick design”) occurs. A quick design focuses on a representation of those aspects of the software that will be visible to end users (e.g., human interface layout or output display formats). The quick design leads to the construction of a prototype. The prototype is deployed and evaluated by stakeholders, who provide feedback that is used to further refine requirements. Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the same time enabling you to better understand what needs to be done.

理想情况下，原型可以作为识别软件需求的机制。如果要构建工作原型，您可以利用现有的程序片段或应用能够快速生成工作程序的工具。第28页

Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is to be built, you can make use of existing program fragments or apply tools that enable working programs to be generated quickly.Page 28

利益相关者和软件工程师都喜欢原型设计范例。用户可以感受到实际的系统，开发人员可以立即构建一些东西。然而，由于以下原因，原型设计可能会出现问题：

Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the actual system, and developers get to build something immediately. Yet, prototyping can be problematic for the following reasons:

1. 利益相关者看到的是软件的工作版本。他们可能没有意识到原型架构（程序结构）也在不断发展。这意味着开发人员可能没有考虑软件的整体质量或长期可维护性。

2. Stakeholders see what appears to be a working version of the software. They may be unaware that the prototype architecture (program structure) is also evolving. This means that the developers may not have considered the overall software quality or long-term maintainability.

3. 作为一名软件工程师，您可能会试图在实现上做出妥协，以使原型快速运行。如果你不小心，这些不太理想的选择现在已经成为不断发展的系统的一个组成部分。

4. As a software engineer, you may be tempted to make implementation compromises to get a prototype working quickly. If you are not careful, these less-than-ideal choices have now become an integral part of the evolving system.

第29页

Page 29

尽管可能会出现问题，但原型设计可以成为软件工程的有效范例。关键是一开始就定义好游戏规则；也就是说，所有利益相关者都应该同意原型的构建部分是为了充当定义需求的机制。通常需要设计一个原型，以便将其演变成最终产品。现实情况是，开发人员可能需要放弃（至少部分放弃）原型，以更好地满足客户不断变化的需求。

Although problems can occur, prototyping can be an effective paradigm for software engineering. The key is to define the rules of the game at the beginning; that is, all stakeholders should agree that the prototype is built in part to serve as a mechanism for defining requirements. It is often desirable to design a prototype so it can be evolved into the final product. The reality is developers may need to discard (at least in part) a prototype to better meet the customer’s evolving needs.

2.5.3 演化过程模型

2.5.3 Evolutionary Process Model

像所有复杂的系统一样，软件会随着时间的推移而发展。随着开发的进行，业务和产品需求经常发生变化，从而导致最终产品的直线路径不切实际。紧迫的市场期限可能导致无法完成全面的软件产品。可以创建产品的有限版本来满足竞争或业务压力，并在更好地理解所有系统功能后发布改进的版本。在这种情况下，您需要一个经过明确设计的流程模型，以适应不断增长和变化的产品。

Software, like all complex systems, evolves over time. Business and product requirements often change as development proceeds, making a straight-line path to an end product unrealistic. Tight market deadlines may make completion of a comprehensive software product impossible. It might be possible to create a limited version of a product to meet competitive or business pressure and release a refined version once all system features are better understood. In a situation like this you need a process model that has been explicitly designed to accommodate a product that grows and changes.

螺旋模型最初由 Barry Boehm [Boe88] 提出，是一种演化的软件过程模型，它将原型设计的迭代性质与瀑布模型的受控和系统方面结合起来。它提供了快速开发越来越完整的软件版本的潜力。

Originally proposed by Barry Boehm [Boe88], the spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. It provides the potential for rapid development of increasingly more complete versions of the software.

使用螺旋模型，软件以一系列渐进的版本进行开发。在早期迭代期间，发布的版本可能是模型或原型。在以后的迭代中，会产生越来越完整的工程系统版本。

Using the spiral model, software is developed in a series of evolutionary releases. During early iterations, the release might be a model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.

螺旋模型分为一组由软件工程团队定义的框架活动。出于说明目的，我们使用前面讨论的通用框架活动。⁴每个框架活动代表图 2.5所示螺旋路径的一段。当这个进化过程开始时，软件团队执行从中心开始以顺时针方向围绕螺旋的一圈所暗示的活动。每次革命时都会考虑风险（第 26 章）。锚点里程碑——沿着螺旋路径达到的工作产品和条件的组合——在每次进化过程中都会被记录下来。

A spiral model is divided into a set of framework activities defined by the software engineering team. For illustrative purposes, we use the generic framework activities discussed earlier.⁴ Each of the framework activities represent one segment of the spiral path illustrated in Figure 2.5. As this evolutionary process begins, the software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center. Risk (Chapter 26) is considered as each revolution is made. Anchor point milestones—a combination of work products and conditions that are attained along the path of the spiral—are noted for each evolutionary pass.

围绕螺旋的第一个回路（从最靠近中心的内部流线开始，如图2.5所示）可能会导致产品规格的开发；随后的螺旋循环可用于开发原型，然后逐步开发更复杂的软件版本。每次经过规划区域都会导致项目计划的调整。成本和进度根据交付后客户的反馈进行调整。此外，项目经理还调整完成软件所需的计划迭代次数。

The first circuit around the spiral (beginning at the inside streamline nearest the center, as shown in Figure 2.5) might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from the customer after delivery. In addition, the project manager adjusts the planned number of iterations required to complete the software.

与其他在软件交付时结束的流程模型不同，螺旋模型可以适应计算机软件的整个生命周期。螺旋模型是开发大型系统和软件的现实方法。它使用原型设计作为风险降低机制。螺旋模型要求直接考虑项目各个阶段的技术风险，如果应用得当，应该在风险出现问题之前将其降低。第30页

Unlike other process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer software. The spiral model is a realistic approach to the development of large-scale systems and software. It uses prototyping as a risk reduction mechanism. The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic.Page 30

但与其他范式一样，螺旋模型也不是万能药。让客户（尤其是在合同情况下）相信渐进方法是可控的可能很困难。它需要大量的风险评估专业知识，并依赖这些专业知识来取得成功。如果重大风险不及时发现和管控，必然会出现问题。

But like other paradigms, the spiral model is not a panacea. It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur.

我们已经注意到，现代计算机软件的特点是不断变化、时间紧迫、迫切需要客户-用户满意度。在许多情况下，上市时间是最重要的管理要求。如果错过了市场窗口，软件项目本身可能就没有意义了。⁵

We have already noted that modern computer software is characterized by continual change, by very tight time lines, and by an emphatic need for customer-user satisfaction. In many cases, time to market is the most important management requirement. If a market window is missed, the software project itself may be meaningless.⁵

进化模型的目的是以迭代或增量的方式开发高质量的软件^{6 。}然而，可以使用演进过程来强调灵活性、可扩展性和开发速度。软件团队及其经理面临的挑战是在这些关键项目和产品参数与客户满意度（软件质量的最终仲裁者）之间建立适当的平衡。第31页

The intent of evolutionary models is to develop high-quality software⁶ in an iterative or incremental manner. However, it is possible to use an evolutionary process to emphasize flexibility, extensibility, and speed of development. The challenge for software teams and their managers is to establish a proper balance between these critical project and product parameters and customer satisfaction (the ultimate arbiter of software quality).Page 31

2.5.4 统一过程模型

2.5.4 Unified Process Model

在某些方面，统一过程（UP）[Jac99]试图利用传统软件过程模型的最佳功能和特性，但以实现敏捷软件开发的许多最佳原则的方式来描述它们（第3章）。统一流程认识到客户沟通和描述客户对系统的看法（用例）的简化方法的重要性。⁷它强调软件架构的重要作用，并“帮助架构师专注于正确的目标，例如可理解性、对未来变化的依赖和重用”[Jac99]。它提出了一个迭代和增量的流程，提供了现代软件开发中必不可少的进化感觉。第32页

In some ways the Unified Process (UP) [Jac99] is an attempt to draw on the best features and characteristics of traditional software process models but characterize them in a way that implements many of the best principles of agile software development (Chapter 3). The Unified Process recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system (the use case).⁷ It emphasizes the important role of software architecture and “helps the architect focus on the right goals, such as understandability, reliance to future changes, and reuse” [Jac99]. It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is essential in modern software development.Page 32

UML（统一建模语言）是为了支持他们的工作而开发的。UML 包含用于面向对象系统的建模和开发的强大符号，并且已成为所有类型建模软件事实上的行业标准。本书第二部分通篇使用 UML 来表示需求和设计模型。附录 1 为那些不熟悉基本 UML 符号和建模规则的人提供了介绍性教程和推荐书籍列表。

UML, the unified modeling language, was developed to support their work. UML contains a robust notation for the modeling and development of object-oriented systems and has became a de facto industry standard for modeling software of all types. UML is used throughout Part Two of this book to represent both requirements and design models. Appendix 1 presents an introductory tutorial and a list of recommended books for those who are unfamiliar with basic UML notation and modeling rules.

图 2.6描述了统一过程的“阶段”，并将它们与第 2.1 节中讨论的通用活动联系起来。

Figure 2.6 depicts the “phases” of the Unified Process and relates them to the generic activities that were discussed in Section 2.1.

UP 的初始阶段是进行客户沟通和规划的阶段。基本业务需求通过一组初步用例（第 7 章）进行描述，这些用例描述了每个主要用户类别希望在软件架构中实现的特性和功能。规划确定资源、评估主要风险并定义软件增量的初步时间表。第33页

The inception phase of the UP is where customer communication and planning takes place. Fundamental business requirements are described through a set of preliminary use cases (Chapter 7) that describe which features and functions each major class of users desires that will become realized in the software architecture. Planning identifies resources, assesses major risks, and defines a preliminary schedule for the software increments.Page 33

细化阶段包括通用流程模型的规划和建模活动（图 2.6）。细化细化和扩展了初步用例，并创建了一个体系结构基线，其中包括软件的五个不同视图——用例模型、分析模型、设计模型、实现模型和部署模型。⁸此时经常对计划进行修改。

The elaboration phase encompasses the planning and modeling activities of the generic process model (Figure 2.6). Elaboration refines and expands the preliminary use cases and creates an architectural baseline that includes five different views of the software—the use case model, the analysis model, the design model, the implementation model, and the deployment model.⁸ Modifications to the plan are often made at this time.

UP 的构建阶段与为通用软件过程定义的构建活动相同。然后，软件增量（即发布）的所有必要和必需的特性和功能都在源代码中实现。当组件被实现时，为每个组件设计并执行单元测试^{9 。}此外，还进行集成活动（组件组装和集成测试）。用例用于派生一套验收测试，这些测试在下一个 UP 阶段开始之前执行。

The construction phase of the UP is identical to the construction activity defined for the generic software process. All necessary and required features and functions for the software increment (i.e., the release) are then implemented in source code. As components are being implemented, unit tests⁹ are designed and executed for each. In addition, integration activities (component assembly and integration testing) are conducted. Use cases are used to derive a suite of acceptance tests that are executed prior to the initiation of the next UP phase.

UP 的过渡阶段包括通用构建活动的后期阶段和通用部署（交付和反馈）活动的第一部分。软件和支持文档提供给最终用户进行 Beta 测试，用户反馈报告缺陷和必要的更改。在过渡阶段结束时，软件增量成为可用的软件版本。

The transition phase of the UP encompasses the latter stages of the generic construction activity and the first part of the generic deployment (delivery and feedback) activity. Software and supporting documentation is given to end users for beta testing, and user feedback reports both defects and necessary changes. At the conclusion of the transition phase, the software increment becomes a usable software release.

UP 的生产阶段与通用流程的部署活动一致。在此阶段，将监视软件的持续使用，提供对操作环境（基础设施）的支持，并提交和评估缺陷报告和更改请求。

The production phase of the UP coincides with the deployment activity of the generic process. During this phase, the ongoing use of the software is monitored, support for the operating environment (infrastructure) is provided, and defect reports and requests for changes are submitted and evaluated.

在进行构建、过渡和生产阶段的同时，下一个软件增量的工作可能已经开始。这意味着五个 UP 阶段不是按顺序发生的，而是交错并发的。

It is likely that at the same time the construction, transition, and production phases are being conducted, work may have already begun on the next software increment. This means that the five UP phases do not occur in a sequence, but rather with staggered concurrency.

应该注意的是，并不是每个软件项目都会执行为 UP 工作流程确定的每个任务。团队调整流程（操作、任务、子任务和工作产品）以满足其需求。

It should be noted that not every task identified for a UP workflow is conducted for every software project. The team adapts the process (actions, tasks, subtasks, and work products) to meet its needs.

2.6 产品与工艺

2.6 Product and Process

表 2.1总结了我们讨论的流程模型的一些优点和缺点。在本书的前几版中，我们讨论了许多其他内容。现实情况是，没有一个流程对于每个项目都是完美的。通常，软件团队会采用 2.5 中讨论的一个或多个流程模型或第 3 章中讨论的敏捷流程模型来满足他们手头项目的需求。第34页

Some of the strengths and weaknesses of the process models we have discussed are summarized in Table 2.1. In previous editions of this book we have discussed many others. The reality is that no process is perfect for every project. Usually the software team adapts one or more of the process models discussed in 2.5 or the agile process models discussed in Chapter 3 to meet their needs for the project at hand.Page 34

如果过程薄弱，最终产品无疑会受到影响。但过分依赖流程也是危险的。在多年前写的一篇短文中，玛格丽特·戴维斯 [Dav95a] 对产品和流程的二元性做出了永恒的评论：

If the process is weak, the end product will undoubtedly suffer. But an obsessive overreliance on process is also dangerous. In a brief essay written many years ago, Margaret Davis [Dav95a] makes timeless comments on the duality of product and process:

人们从创作过程中获得的满足感与从最终产品中获得的满足感一样多（甚至更多）。艺术家喜欢画笔的笔触，就像喜欢框架的结果一样。作家喜欢寻找合适的隐喻，就像喜欢完成书一样。作为一名创意软件专业人士，您还应该从过程中获得与最终产品一样的满足感。随着软件工程的不断发展，产品和流程的二元性是保持创意人员参与的重要因素之一。

People derive as much (or more) satisfaction from the creative process as they do from the end product. An artist enjoys the brush strokes as much as the framed result. A writer enjoys the search for the proper metaphor as much as the finished book. As a creative software professional, you should also derive as much satisfaction from the process as the end product. The duality of product and process is one important element in keeping creative people engaged as software engineering continues to evolve.

2.7 总结

2.7 Summary

软件工程的通用过程模型包含一组框架和伞式活动、操作和工作任务。各种过程模型中的每一个都可以通过不同的过程流来描述，即框架活动、操作和任务如何按顺序和时间顺序组织的描述。过程模式可用于解决软件过程中遇到的常见问题。

A generic process model for software engineering encompasses a set of framework and umbrella activities, actions, and work tasks. Each of a variety of process models can be described by a different process flow—a description of how the framework activities, actions, and tasks are organized sequentially and chronologically. Process patterns can be used to solve common problems that are encountered as part of the software process.

规范性过程模型已被应用多年，旨在为软件开发带来秩序和结构。这些模型中的每一个都提出了稍微不同的流程，但都执行相同的一组通用框架活动：通信、规划、建模、构建和部署。

Prescriptive process models have been applied for many years in an effort to bring order and structure to software development. Each of these models suggests a somewhat different process flow, but all perform the same set of generic framework activities: communication, planning, modeling, construction, and deployment.

顺序过程模型，例如瀑布模型，是最古老的软件工程范例。他们提出的线性流程通常与软件世界中的现代现实（例如，持续变化、不断发展的系统、紧迫的时间线）不一致。然而，它们确实适用于需求定义明确且稳定的情况。

Sequential process models, such as the waterfall model, are the oldest software engineering paradigms. They suggest a linear process flow that is often inconsistent with modern realities (e.g., continuous change, evolving systems, tight time lines) in the software world. They do, however, have applicability in situations where requirements are well defined and stable.

增量过程模型本质上是迭代的，并且可以非常快速地生成软件的工作版本。演化过程模型认识到大多数软件工程项目的迭代、增量性质，并旨在适应变化。进化模型，例如原型设计和螺旋模型，可以快速生成增量工作产品（或软件的工作版本）。这些模型可以应用于所有软件工程活动——从概念开发到长期系统维护。

Incremental process models are iterative in nature and produce working versions of software quite rapidly. Evolutionary process models recognize the iterative, incremental nature of most software engineering projects and are designed to accommodate change. Evolutionary models, such as prototyping and the spiral model, produce incremental work products (or working versions of the software) quickly. These models can be adopted to apply across all software engineering activities—from concept development to long-term system maintenance.

统一流程是一个“用例驱动、以体系结构为中心、迭代和增量”的软件流程，被设计为 UML 方法和工具的框架。

The Unified Process is a “use case driven, architecture-centric, iterative and incremental” software process designed as a framework for UML methods and tools.

问题与思考点

Problems and Points to Ponder

2.1. Baetjer [Bae98] 指出：“该过程提供了用户和设计者之间、用户和不断发展的工具之间以及设计者和不断发展的工具[技术]之间的交互。” 列出五个问题：(1) 设计者应该问用户，(2) 用户应该问设计者，(3) 用户应该问自己要构建的软件产品，(4) 设计者应该问自己关于要构建的软件产品。要构建的内容以及构建它的过程。

2.1. Baetjer [Bae98] notes: “The process provides interaction between users and designers, between users and evolving tools, and between designers and evolving tools [technology].” List five questions that (1) designers should ask users, (2) users should ask designers, (3) users should ask themselves about the software product that is to be built, and (4) designers should ask themselves about the software product that is to be built and the process that will be used to build it.

第36页2.2. 讨论第 2.1 节中描述的各种流程之间的差异。确定可能适用于所描述的每个通用流程的问题类型。

Page 362.2. Discuss the differences among the various process flows described in Section 2.1. Identify the types of problems that might be applicable to each of the generic flows described.

2.3. 尝试为沟通活动制定一套行动。选择一个操作，并为其定义一组任务。

2.3. Try to develop a set of actions for the communication activity. Select one action, and define a task set for it.

2.4. 当您遇到两个利益相关者对于软件应该是什么有冲突的想法时，沟通过程中的一个常见问题就会出现。也就是说，它们具有相互冲突的要求。开发解决此问题的流程模式并提出有效的解决方法。

2.4. A common problem during communication occurs when you encounter two stakeholders who have conflicting ideas about what the software should be. That is, they have mutually conflicting requirements. Develop a process pattern that addresses this problem and suggest an effective approach to it.

2.5. 提供三个适合瀑布模型的软件项目示例。请明确点。

2.5. Provide three examples of software projects that would be amenable to the waterfall model. Be specific.

2.6。提供三个适合原型模型的软件项目示例。请明确点。

2.6. Provide three examples of software projects that would be amenable to the prototyping model. Be specific.

2.7. 当您沿着螺旋流程向外移动时，您对正在开发或维护的软件有什么看法？

2.7. As you move outward along the spiral process flow, what can you say about the software that is being developed or maintained?

2.8. 是否可以组合流程模型？如果是这样，请提供一个例子。

2.8. Is it possible to combine process models? If so, provide an example.

2.9. 开发质量“足够好”的软件有哪些优点和缺点？也就是说，当我们强调开发速度而不是产品质量时会发生什么？

2.9. What are the advantages and disadvantages of developing software in which quality is “good enough”? That is, what happens when we emphasize development speed over product quality?

2.10. 有可能证明一个软件组件甚至整个程序都是正确的吗？那么为什么不是每个人都这样做呢？

2.10. It is possible to prove that a software component and even an entire program is correct? So why doesn’t everyone do this?

2.11. 统一过程和UML是一回事吗？解释你的答案。

2.11. Are the Unified Process and UML the same thing? Explain your answer.